Re: locale-related build problems

[Dimitry Andric]

On 2010-01-03 15:03, Jilles Tjoelker wrote:

The build system appears not to cope with locales. My guess is that
you're using Turkish locale, which has dotless and dotted uppercase and
lowercase 'i', where the uppercase version of the dotted 'i' is an
uppercase dotted 'I'. awk(1) knows about this and generates a file that
conforms to Turkish conventions but obviously will not work.

As a workaround, you can run your builds with LC_ALL=C in the
environment, disabling locale support. (e.g. env LC_ALL=C make
buildkernel).

This should be fixed by adding LC_ALL=C somewhere in the build process,
possibly only for these awk commands.


Ah yes, this must be the cause.  I can reproduce E.O.'s problem by
setting LC_ALL=tr_TR.ISO8859-9 and doing a buildkernel.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: locale-related build problems

[Dimitry Andric]

On 2010-01-03 15:03, Jilles Tjoelker wrote:

This should be fixed by adding LC_ALL=C somewhere in the build process,
possibly only for these awk commands.


Here is a quite minimal diff to do so, at least for the buildkernel
part.

In any case, it looks like awk is used quite a lot in other places
during buildworld; some of these invocations already use LC_ALL=C, most
of them do not.  There are even invocations of sh using LC_ALL=C. :)

Instead of peppering the whole tree with LC_ALL=C insertions, would it
make sense to simply set LC_ALL=C globally during building world and
kernel?  Or are there parts that actually use locales during the build?


Index: sys/conf/kern.pre.mk
===
--- sys/conf/kern.pre.mk(revision 201193)
+++ sys/conf/kern.pre.mk(working copy)
@@ -14,7 +14,7 @@
 
 M=	${MACHINE_ARCH}
 
-AWK?=		awk

+AWK?=  LC_ALL=C awk
 LINT?= lint
 NM?=   nm
 OBJCOPY?=  objcopy
Index: sys/conf/kmod.mk
===
--- sys/conf/kmod.mk(revision 201193)
+++ sys/conf/kmod.mk(working copy)
@@ -60,7 +60,7 @@
 #  Unload a module.
 #
 
-AWK?=		awk

+AWK?=  LC_ALL=C awk
 KMODLOAD?= /sbin/kldload
 KMODUNLOAD?=   /sbin/kldunload
 OBJCOPY?=  objcopy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: immense delayed write to file system (ZFS and UFS2), performance issues

[Dimitry Andric]

On 2010-01-27 00:15, Dan Naumov wrote:

Can anyone confirm that using the WDIDLE3 utility on the 2TB WD20EADS
discs will not cause any issues if these disks are part of a ZFS
mirror pool? I do have backups of data, but I would rather not spend
the time rebuilding the entire system and restoring enormous amounts
of data over a 100mbit network unless I absolutely have to :)


Sorry to bump into this thread so late, but for some of my servers I
have been using a patch for atacontrol, to turn the APM features of the
disk(s) off, for a long time.  This is mostly noticable with 2.5"
notebook disks, which "click" like crazy all the time. :)

E.g. if you run "atacontrol cap $device", and you see in the output that
"advanced power management" is supported, you might be able to stop the
disk from spinning down by turning the APM feature off.

Patch is at .  This
should apply to 8-STABLE, no idea about older branches.

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

Re: booting off GPT partitions

[Dimitry Andric]

On 2010-01-27 22:27, John Baldwin wrote:

GPT was defined along with EFI, so many folks assume that you have to use EFI
to boot a GPT-labelled disk.  However, FreeBSD has its own BIOS-based
bootstrap that can handle GPT-labelled disks.  I doubt the SuperMicro tech is
familiar with that case.  I thought I heard that some folks had added GPT
support to grub as well.


However, this won't boot disks larger than 2TiB, right?  At least not
without BIOS support...
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: booting off GPT partitions

[Dimitry Andric]

On 2010-01-28 13:06, Robert Noland wrote:

John or Marcel can correct me, but I don't think that this is an issue.
The bootstrap is located in the pmbr in sector 0 and the GPT headers and
tables are in sectors 1 - 34.  The bootstrap code knows how to read the
GPT tables and can deal with>  2 tb lba's.


Ah yes, I see it now.  It uses EDD packets with the BIOS int 13
interface, which apparently have a 64-bit LBA.  This should support up
to 8 ZiB with 512-byte sectors...

OTOH, I have no idea how well most BIOSes actually implement this.
Since many OSes simply don't support anything over 2^32 sectors, I would
not be amazed to find much BIOSes out there that behave the same.  Or am
I too paranoid now? :)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: lzma support in `stable' has potential issues

[Dimitry Andric]

On 2010-05-24 18:15, Garrett Cooper wrote:
> No worries. Here's what I did to actually reproduce the issue (just to 
> provide more data):
> 
> - Install 8.0-RELEASE amd64 with minimal from sysinstall.
> - pkg_add -r subversion vim-lite
> - cd /usr/src && svn co svn://svn.freebsd.org/base/head .

Just a note, you are getting -CURRENT sources here, not 8-STABLE.  Since
your starting post was about "Upgrading to 8-STABLE", is this what you
intended?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: SUJ Patches for 8.X ???

[Dimitry Andric]

On 2010-06-04 01:24, David Rhodus wrote:
> Anyone have a SUJ patch set for 8.x ?

http://www.andric.com/freebsd/suj/suj-stable8-r208287-1.diff.bz2

This backports SUJ from head to stable/8 (at r208799), by cherry-picking
the following revisions:

  r207141 | jeff | 2010-04-24 09:05:35 +0200 (Sat, 24 Apr 2010) | 7 lines
  r207142 | pjd | 2010-04-24 09:36:33 +0200 (Sat, 24 Apr 2010) | 2 lines
  r207143 | pjd | 2010-04-24 09:54:49 +0200 (Sat, 24 Apr 2010) | 2 lines
  r207144 | pjd | 2010-04-24 09:58:59 +0200 (Sat, 24 Apr 2010) | 3 lines
  r207145 | jeff | 2010-04-24 09:59:45 +0200 (Sat, 24 Apr 2010) | 4 lines
  r207309 | jeff | 2010-04-28 09:26:41 +0200 (Wed, 28 Apr 2010) | 2 lines
  r207310 | jeff | 2010-04-28 09:57:37 +0200 (Wed, 28 Apr 2010) | 5 lines
  r207421 | jeff | 2010-04-30 06:21:22 +0200 (Fri, 30 Apr 2010) | 7 lines
  r207462 | edwin | 2010-05-01 11:05:06 +0200 (Sat, 01 May 2010) | 7 lines
  r207476 | emaste | 2010-05-01 20:56:45 +0200 (Sat, 01 May 2010) | 4 lines
  r207741 | jeff | 2010-05-07 10:20:56 +0200 (Fri, 07 May 2010) | 8 lines
  r207742 | jeff | 2010-05-07 10:45:21 +0200 (Fri, 07 May 2010) | 7 lines
  r208241 | jeff | 2010-05-18 03:45:28 +0200 (Tue, 18 May 2010) | 11 lines
  r208287 | jeff | 2010-05-19 08:18:01 +0200 (Wed, 19 May 2010) | 11 lines

I have tested:
- Applying this diff to stable/8 at r208799 (any other rev is NOT
  guaranteed to work, but there is a good chance, if not too far off)
- Doing a full buildworld, buildkernel, installkernel, reboot,
  installworld and mergemaster.
- Enabling SUJ on a big filesystem with "tunefs -j enable".
- Randomly resetting the box during a large copy operation on that
  filesystem, seeing the journal is replayed at boot time, and the
  filesystem recovered.

That said, there is NO WARRANTY that this patch works properly.  It
could hose all your filesystems, and/or cause irreversible damage to
your system.  Most likely, even.  You have been warned. :)

Also, please do NOT bother Jeff Roberson about this, as he is probably
busy enough supporting SUJ in head. :)  Instead, direct any problem
reports to me first, or to the freebsd-stable mailing list, if you
prefer.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 7.0 Weird acpi.ko in the dmesg

[Dimitry Andric]

Abdullah Ibn Hamad Al-Marri wrote:

link_elf: symbol msleep undefined
^^^
KLD file acpi.ko - could not finalize loading
^


Perhaps kldxref failed when you installed this kernel?  Or possibly you
have an outdated acpi.ko module around.  What's the output of:

find /boot -type f -name 'acpi*.ko'
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD 7.0 Weird acpi.ko in the dmesg

[Dimitry Andric]

Abdullah Ibn Hamad Al-Marri wrote:

find /boot -type f -name 'acpi*.ko'
/boot/modules/acpi.ko
/boot/modules/acpi_asus.ko
/boot/modules/acpi_panasonic.ko
/boot/modules/acpi_toshiba.ko
/boot/modules/acpi_video.ko
/boot/modules/acpi_fujitsu.ko
/boot/modules/acpi_ibm.ko
/boot/modules/acpi_sony.ko
/boot/modules/acpi_dock.ko


Ah yes, these don't belong here, they should be in /boot/kernel, AFAIK.
But I don't understand why there aren't any acpi modules in
/boot/kernel?  These should have been put there when you installed or
built 7.0-BETA4.

Anyway, you can try to temporarily unset module_path when loading your
kernel, e.g. type:

unset module_path

at the loader prompt, and then boot with "boot" or "boot -s".
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 7.0 Kernel install problem

[Dimitry Andric]

On 2008-03-01 01:32, Alex de Kruijff wrote:
> kldxref /boot/kernel
> kldxref: file isn't dynamically-linked
...
> Should I be worried?

You're probably upgrading from 6.x?  The old kldxref doesn't grok the
new kernel format, apparently.  So you might want to use the kldxref
from your buildworld instead:

/usr/obj/usr/src/usr.sbin/kldxref/kldxref /boot/kernel
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: INET6 required for SCTP in 7.0?

[Dimitry Andric]

On 2008-03-05 22:42, Peter Wemm wrote:
> Oh, one more thing.  If you are IPv6-enabled, you get to bypass the 10
> minute greylisting delay on mx1.freebsd.org.  Your email goes through
> instantly instead of potentially being delayed by 10-30 minutes.

Until the spammers start using IPv6... Then we'll know it's gone
mainstream. :/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: BTX on USB pen drive

[Dimitry Andric]

On 2008-03-07 15:13, John Baldwin wrote:
> Try this instead:
> 
> http://people.freebsd.org/~jhb/patches/btx_real.patch

Hi John,

I've encounted way too many machines already with BIOSes that clash with
the regular btx loader... :(

Might it not be a nice idea to put out a RELENG_7 or RELENG_7_0 bootonly
CD image with this patch applied?  I'm sure many people won't be able to
build this themselves, but they could just download a prebuilt image to
test booting. :)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: BTX on USB pen drive

[Dimitry Andric]

On 2008-03-08 13:16, Torfinn Ingolfsen wrote:
> I have btx.S revision:
>  * $FreeBSD: src/sys/boot/i386/btx/btx/btx.S,v 1.44 2006/12/06 17:45:35
> jhb Exp $
> 
> Is the patch supposed to work on that one?

No, update it to 1.45 (=HEAD) and then apply the patch, that's much
easier.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: BTX on USB pen drive

[Dimitry Andric]

On 2008-03-07 23:51, Dimitry Andric wrote:
>> http://people.freebsd.org/~jhb/patches/btx_real.patch
> Might it not be a nice idea to put out a RELENG_7 or RELENG_7_0 bootonly
> CD image with this patch applied?  I'm sure many people won't be able to
> build this themselves, but they could just download a prebuilt image to
> test booting. :)

Okay, I thought I might better do some work for this myself, instead of
just asking.  So I've built a RELENG_7_0 release with the above patch,
and some other minor ones I'm using.  The bootonly ISO is here:

http://www.andric.com/freebsd/btxtest/7.0-BTXTEST-i386-bootonly.iso

MD5: 4e9c05bf55bc9329b1aecaa2aa336a7f
SHA256: 63cca954f04f2a652519cd5ffd5fe9e7ea36a97bad115b6c2d9754fe5e918528

Find the other ISOs and the complete patch I've applied in
<http://www.andric.com/freebsd/btxtest/>, but note the disc1-disc3 ISOs
miss packages, I didn't build those. 

With this ISO I can finally get FreeBSD booting on my ThinkPad X41, for
which I use an external USB DVD drive.  Every FreeBSD release until now
has crashed on this combination... :)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to build profiled libraries on RELENG_7?

[Dimitry Andric]

On 2008-03-09 20:46, Lenar Tukhvatullin wrote:
> I need profiled versions of system libraries.
> 
> I put WITHOUT_PROFILE=NO in /etc/src.conf (/etc/make.conf not present)

This is incorrect, read src.conf(5):

 The values of variables are ignored regardless of their setting; even if
 they would be set to ``FALSE'' or ``NO''.  Just the existence of an
 option will cause it to be honoured by make(1).

So, do NOT specify the WITHOUT_PROFILE option anywhere, and you should
get profiled libs. :)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: broken MBR

[Dimitry Andric]

On 2008-03-12 14:32, Yuri Pankov wrote:
> boot0cfg can't install `mbr', you need to use fdisk for that as shown in 
> boot0cfg(8) manpage, EXAMPLES section.

He'll probably need to enable geom footshooting too... :)

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

Re: FreeBSD 7.0 WITHOUT Heimdal

[Dimitry Andric]

On 2008-04-10 13:24, Gunnar Flygt wrote:
> In earlier version of FreeBSD I've been able to NOT include the heimdal
> delivered with the system, by providing the flag NO_KERBEROS=yes in
> /etc/make.conf
> 
> In 7.0 there is no detection of such a flag.
 
All the NO_XXX flags have been obsoleted, use WITHOUT_KERBEROS=yes
instead.  See src.conf(5) for more information.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD 7.0 WITHOUT Heimdal

[Dimitry Andric]

On 2008-04-10 13:56, Dimitry Andric wrote:
> All the NO_XXX flags have been obsoleted, use WITHOUT_KERBEROS=yes
> instead.  See src.conf(5) for more information.

Btw, you also need to put these directives in /etc/src.conf, not
/etc/make.conf.  See /usr/src/UPDATING, under 20060317.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: broken re(4)

[Dimitry Andric]

On 2008-05-29 11:58, Gerrit Kühn wrote:
> Can I do anything else? Is the newer patch (from yesterday) in your
> directory above worth giving a try?

FYI, that patch doesn't compile, due to a typo... Fix below:

--- re.HEAD.20080528.orig   2008-05-29 13:08:15.0 +0200
+++ re.HEAD.200805282008-05-29 13:07:28.0 +0200
@@ -352,7 +352,7 @@
 +  if ((sc->rl_flags & RL_FLAG_PAR) != 0) {
 +  /* XXX Should have a way to get station address from EEPROM. */
 +  uint32_t vpdc, word;
-+  int offet, verr;
++  int offset, verr;
 +
 +  if (pci_find_extcap(sc->rl_dev, PCIY_VPD, &vpdc) == 0) {
 +  for (offset = 0; offset < 0x20; offset += 4) {

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

Re: broken re(4)

[Dimitry Andric]

On 2008-05-29 17:13, Gerrit Kühn wrote:
> On Thu, 29 May 2008 13:10:48 +0200 Dimitry Andric <[EMAIL PROTECTED]>
> Meanwhile I have set up two more machines. Now I have 5 ITX systems, each
> with 2 re-NICs, and only one is behaving strange.

Just as a data point, my ITX board is a JetWay J7F4K1G2E. 

...
re0:  port 0xf000-0xf0ff 
mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on pci0
re0: Chip rev. 0x1800
re0: MAC rev. 0x
miibus0:  on re0
rgephy0:  PHY 1 on miibus0
rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto
re0: Ethernet address: 00:30:18:a6:f1:a8
re0: [FILTER]
re1:  port 0xf200-0xf2ff 
mem 0xfdffe000-0xfdffe0ff irq 19 at device 11.0 on pci0
re1: Chip rev. 0x1800
re1: MAC rev. 0x
miibus1:  on re1
rgephy1:  PHY 1 on miibus1
rgephy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto
re1: Ethernet address: 00:30:18:a6:f1:a9
re1: [FILTER]
atapci0:  port 
0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f,0xf400-0xf4ff
 irq 20 at device 15.0 on pci0
atapci0: [ITHREAD]

As you can see, re0 is on irq 18, re1 on irq 19 and the SATA controller
on irq 20, so no conflicts there.

It also seems to work okay with this latest patch.



> The only hardware thing
> that is different in this system from the others is an additional
> SATA-controller. Can there be conflicts with this card which are
> triggering the problems?

I'd just suspect a bad board instead...

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

Re: broken re(4)

[Dimitry Andric]

On 2008-05-30 07:03, Pyun YongHyeon wrote:
> Since you're running this patch would you post dmesg output related
> with re(4)? Also please post the output of "devinfo -rv | grep
> oui".

dmesg
--
Copyright (c) 1992-2008 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 is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.0-STABLE #2: Thu May 29 13:00:50 CEST 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/TENSOR
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: VIA Esther processor 1200MHz (1200.01-MHz 686-class CPU)
  Origin = "CentaurHauls"  Id = 0x6a9  Stepping = 9
  
Features=0xa7c9baff
  Features2=0x181
  VIA Padlock Features=0x3fcc
real memory  = 518914048 (494 MB)
avail memory = 498270208 (475 MB)
ACPI APIC Table: 
ioapic0  irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0:  on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a (3) failed
acpi0: reservation of 10, 1ede (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
cpu0:  on acpi0
est0:  on cpu0
p4tcc0:  on cpu0
acpi_button0:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
vgapci0:  mem 
0xf400-0xf7ff,0xfb00-0xfbff irq 16 at device 0.0 on pci1
re0:  port 0xf000-0xf0ff 
mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on pci0
re0: Chip rev. 0x1800
re0: MAC rev. 0x
miibus0:  on re0
rgephy0:  PHY 1 on miibus0
rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto
re0: Ethernet address: 00:30:18:a6:f1:a8
re0: [FILTER]
re1:  port 0xf200-0xf2ff 
mem 0xfdffe000-0xfdffe0ff irq 19 at device 11.0 on pci0
re1: Chip rev. 0x1800
re1: MAC rev. 0x
miibus1:  on re1
rgephy1:  PHY 1 on miibus1
rgephy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto
re1: Ethernet address: 00:30:18:a6:f1:a9
re1: [FILTER]
atapci0:  port 
0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f,0xf400-0xf4ff
 irq 20 at device 15.0 on pci0
atapci0: [ITHREAD]
ata2:  on atapci0
ata2: [ITHREAD]
ata3:  on atapci0
ata3: [ITHREAD]
atapci1:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfa00-0xfa0f at device 15.1 on pci0
ata0:  on atapci1
ata0: [ITHREAD]
ata1:  on atapci1
ata1: [ITHREAD]
uhci0:  port 0xf900-0xf91f irq 21 at device 16.0 on 
pci0
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0:  on uhci0
usb0: USB revision 1.0
uhub0:  on usb0
uhub0: 2 ports with 2 removable, self powered
uhci1:  port 0xf800-0xf81f irq 21 at device 16.1 on 
pci0
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1:  on uhci1
usb1: USB revision 1.0
uhub1:  on usb1
uhub1: 2 ports with 2 removable, self powered
uhci2:  port 0xf700-0xf71f irq 21 at device 16.2 on 
pci0
uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2:  on uhci2
usb2: USB revision 1.0
uhub2:  on usb2
uhub2: 2 ports with 2 removable, self powered
uhci3:  port 0xf600-0xf61f irq 21 at device 16.3 on 
pci0
uhci3: [GIANT-LOCKED]
uhci3: [ITHREAD]
usb3:  on uhci3
usb3: USB revision 1.0
uhub3:  on usb3
uhub3: 2 ports with 2 removable, self powered
ehci0:  mem 0xfdffd000-0xfdffd0ff irq 21 at 
device 16.4 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb4: waiting for BIOS to give up control
usb4: timed out waiting for BIOS
usb4: EHCI version 1.0
usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3
usb4:  on ehci0
usb4: USB revision 2.0
uhub4:  on usb4
uhub4: 8 ports with 8 removable, self powered
isab0:  at device 17.0 on pci0
isa0:  on isab0
pci0:  at device 17.5 (no driver attached)
acpi_tz0:  on acpi0
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A, console
sio0: [FILTER]
sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
sio1: [FILTER]
ppc0:  port 0x378-0x37f irq 7 on acpi0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
ppbus0:  on ppc0
ppbus0: [ITHREAD]
plip0:  on ppbus0
lpt0:  on ppbus0
lpt0: Interrupt-driven port
ppi0:  on ppbus0
ppc0: [GIANT-LOCKED]
ppc0: [ITHREAD]
pmtimer0 on isa0
orm0:  at iomem 0xc-0xc pnpid ORM on isa0
atkbdc0:  at port 0x60,0x64 on isa0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
Timecounter "TSC" frequency 127233 Hz quality 800
Timecounters tick every 1.000 msec
ad4: 114473MB  at ata2-master SATA150
Trying to mount root from ufs:/dev/ad4s1a

Re: OpenBSD's spamd.

[Dimitry Andric]

Oliver Fromme wrote:
> What does stuttering mean?  Is it similar to sendmail's
> "greet_pause" feature?

See here:

http://www.ualberta.ca/~beck/nycbug06/spamd/mgp00014.html

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

gif problems in -STABLE

[Dimitry Andric]

Hi,

I just updated one of my machines from RELENG_6 as of 2006-11-03, to
RELENG_6 as of 2006-12-29.  This caused the IPv6 tunnel which this box
uses, which had been doing fine for months, to suddenly stop working.

Reverting to my 2006-11-03 kernel restored the tunnel again, so my ISP
could be ruled out. :)

The symptoms are that the IPv6 default gateway cannot be reached, and
you'll get "ping6: sendmsg: No route to host" when you try to ping it.

For some reason, the ifconfig command now fails to create the proper
routing table entries.  With the 2006-11-03 kernel, if I configure my
gif0 tunnel as follows:

ifconfig gif0 create
ifconfig gif0 213.154.244.69 193.109.122.244
ifconfig gif0 inet6 2001:7b8:2ff:146::2 2001:7b8:2ff:146::1 prefixlen 128
route add -inet6 default 2001:7b8:2ff:146::1

I get the following entries in the routing table:

Internet6:
Destination   Gateway   Flags  
Netif Expire
::/96 ::1   UGRSlo0 
=>
default   2001:7b8:2ff:146::1   UGSgif0
::1   ::1   UHL lo0
:::0.0.0.0/96 ::1   UGRSlo0
2001:7b8:2ff:146::1   link#6UHLgif0
2001:7b8:2ff:146::2   link#6UHL lo0
...

If I use the 2006-12-29 kernel, the routing table after exactly the same
sequence of commands is:

Internet6:
Destination   Gateway   Flags  
Netif Expire
::/96 ::1   UGRSlo0 
=>
default   2001:7b8:2ff:146::1   UGSgif0
::1   ::1   UHL lo0
:::0.0.0.0/96 ::1   UGRSlo0
2001:7b8:2ff:146::2   link#6UHL lo0
...

So, for some reason, the 2001:7b8:2ff:146::1 entry is not automatically
created anymore.  Of course, you could add this manually, but it's
rather strange that this behaviour has changed.

After some Googling, I found this thread about -current, which seems to
describe approximately the same problem:
http://lists.freebsd.org/pipermail/freebsd-current/2006-December/067830.html

However, the thread seems to have no real conclusion as to what the
cause or proper solution is.  There are two possible solutions
mentioned, though:

1) Using something like:
ipv6_defaultrouter="::1 -ifp gif0"

This doesn't work for me, unless I set the prefixlen for the whole gif0
tunnel to 64; but in that case I don't need the ::1 -ifp stuff either.

2) Using something like:
ipv6_ifconfig_gif0="2001:7b8:2ff:146::2 prefixlen 126"

This does work, though I find it strange that such functionality is
changed so shortly before a release. :)

Does anyone have a clue where this changed behaviour comes from, or
where in the source tree I should look to find the commit that caused
it?

Maybe it would be nicer to revert to the previous behaviour for
6.2-RELEASE, since it will cause many non-working tunnels when people
upgrade.  Or otherwise at least put a big notice in UPDATING or the
release notes. :)

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

Re: gif problems in -STABLE

[Dimitry Andric]

Henrik Brix Andersen wrote:
> On Sat, Dec 30, 2006 at 02:56:35AM +0100, Dimitry Andric wrote:
>> For some reason, the ifconfig command now fails to create the proper
>> routing table entries.  With the 2006-11-03 kernel, if I configure my
>> gif0 tunnel as follows:
>>
>> ifconfig gif0 create
>> ifconfig gif0 213.154.244.69 193.109.122.244
>> ifconfig gif0 inet6 2001:7b8:2ff:146::2 2001:7b8:2ff:146::1 prefixlen 128
>> route add -inet6 default 2001:7b8:2ff:146::1
> 
> Apart from the two IPv4 endpoint addresses you also assign two IPv6
> addresses with prefixlen 128 to the gif0 interface? Looks weird to
> me...

This is the syntax my IPv6 ISP (sixxs.net) specifies, here:
http://www.sixxs.net/faq/connectivity/?faq=ossetup&os=freebsd

If you Google around for IPv6 gif tunnel setup information, you'll see
this particular syntax many times.  It used to work for several years,
but if someone can point out an obvious error in it, please let me
know. :)

There's also a similar syntax in the FreeBSD handbook, though it doesn't
mention the prefixlen at all:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-ipv6.html#AEN39629

Moreover, the syntax mentioned in the handbook doesn't even work:

# ifconfig gif0 create
# ifconfig gif0
gif0: flags=8010 mtu 1280
# ifconfig gif0 tunnel 213.154.244.69 193.109.122.244
# ifconfig gif0 inet6 alias 2001:7b8:2ff:146::2 2001:7b8:2ff:146::1
ifconfig: ioctl (SIOCAIFADDR): Invalid argument

The particular thing that I observe, is that when you configured the
gif tunnel with:

ifconfig gif0 inet6 2001:7b8:2ff:146::2 2001:7b8:2ff:146::1 prefixlen 128 

the kernel *used* to automagically create two routing table entries:

2001:7b8:2ff:146::1   link#6UHLgif0
2001:7b8:2ff:146::2   link#6UHL lo0

but as of some date between 2006-11-03 and 2006-12-29, this behaviour
changed, and it now only creates *one* routing table entry:

2001:7b8:2ff:146::2   link#6UHL lo0

And I'm only asking why this was changed.


> Try this configuration in /etc/rc.conf instead:
> 
> ipv6_defaultrouter="2001:7b8:2ff:146::1"
> gif_interfaces="gif0"
> gifconfig_gif0="213.154.244.69 193.109.122.244"
> ipv6_ifconfig_gif0="2001:7b8:2ff:146::2 prefixlen 127"

Doesn't work for me; if I specify prefixlen 127 instead of 126, I get:

ping6: UDP connect: No route to host

when trying to ping the other endpoint of the tunnel, and the required
routing table entry is *not* present:

Internet6:
Destination   Gateway   Flags  
Netif Expire
::/96 ::1   UGRSlo0
::1   ::1   UHL lo0
:::0.0.0.0/96 ::1   UGRSlo0
2001:7b8:2ff:146::2   link#6UHL lo0 
=>
2001:7b8:2ff:146::2/127   link#6UC gif0
...

In my case, the 2001:7b8:2ff:146::2/127 route is also not enough to
reach 2001:7b8:2ff:146::1; you really have to use a prefixlen of 126 for
that.

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

Re: gif problems in -STABLE

[Dimitry Andric]

Sean C. Farley wrote:
>> I just updated one of my machines from RELENG_6 as of 2006-11-03, to
>> RELENG_6 as of 2006-12-29.  This caused the IPv6 tunnel which this box
>> uses, which had been doing fine for months, to suddenly stop working.
...
>> For some reason, the ifconfig command now fails to create the proper
>> routing table entries.  With the 2006-11-03 kernel, if I configure my
>> gif0 tunnel as follows:
> 
> I can confirm my setup with Hurricane Electric also started failing at
> some point:
...
> I needed to add the following to restore the old (working) behavior:
> ipv6_static_routes="defroute"
> ipv6_route_defroute=":::::1C -interface gif0"

By doing some nice bisection debugging, I've narrowed the problem down
to this specific commit:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/nd6.c#rev1.48.2.16

If you revert this change, tunnel configuration will work as before
again.  I'm now investigating the diff itself, to see if I can find an
error in there anywhere... :)

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

Re: 2.4TB disk - MBR and GPT coexist?

[Dimitry Andric]

Jo Rhett wrote:
> Sysinstall recognized the drive properly and everything looked dandy
> during install.  However, it turns out that fdisk and bsdlabel both just
> chopped off the last partition at 248GB.  (why 248gb and not 2tb?)

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

Re: IPv6 over gif(4) broken in 6.2-RELEASE?

[Dimitry Andric]

Bruce A. Mah wrote:
>>  I remember Dimitry Andric reported the same problem on -stable on 30
>>  Dec, and after he reverted rev.1.48.2.16 it worked fine again.  Do
>>  you have the symptom even on 6.2-RELEASE?  Since RELENG_6_2_0_RELEASE
>>  did not have the change, I thought there was no problem.
...
> On my 6-STABLE system (which appears to be working fine), I still have
> the change from 1.48.2.16, I only backed out .15 and .14.  I didn't try
> my diff on the 6.2-RC2 and 6.2-RELEASE machines yet.
> 
> Hmmm...I was looking for that bug report before, but I couldn't find it.
>  It's not clear to me how 1.48.2.16 is involved...hmmm...

I originally reported this here:
http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031809.html

and later I found out it was caused by commit 1.48.2.16:
http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031853.html

I'll shoot in a regular PR later tonight...
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPv6 over gif(4) broken in 6.2-RELEASE?

[Dimitry Andric]

Bruce A. Mah wrote:
>> and later I found out it was caused by commit 1.48.2.16:
>> http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031853.html
> 
> This isn't consistent with what I'm finding.  For one thing, rev.
> 1.48.2.16 of nd6.c isn't in 6.2-RELEASE but I saw the problem there
> anyways.  Also, that's not the change I made to my local sources to get
> my gif(4) tunnel working.  Are you sure about this?  :-)

I'm following -STABLE, and 1.48.2.16 is in there.  Since it was
committed on 29 Nov, I suspected it would end up in -RELEASE, but
apparently not. :)

I explicitly tried reverting just this one commit, and for me it solved
the problem (i.e. the automagical addition of needed routing entries).

So for you, reverting the combination of 1.48.2.14 and .15 works?  Maybe
there is something else involved too, for example the route command
itself?

I'll have to experiment a bit further, I guess.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPv6 over gif(4) broken in 6.2-RELEASE?

[Dimitry Andric]

Bruce A. Mah wrote:

Just to confirm, you're dealing with a gif(4) interface with an
explicitly-configured destination address and a 128-bit prefixlen, yes?


Yes.  The specific line in my rc.conf is:

ipv6_ifconfig_gif0="2001:7b8:2ff:146::2 2001:7b8:2ff:146::1 prefixlen 128"



Maybe
there is something else involved too, for example the route command
itself?

Not sure what you mean by this exactly...???...


I mean that it may be that between -RELEASE and -STABLE, other things
have changed, e.g. network rc scripts, /sbin/route itself, etc, which
may also influence this behaviour.  I'm sure more than only nd6.c
changed. :)

However, for me, with the whole system at -STABLE (as of Jan 11), I
verified the following results again just now:

nd6.c rev   state
-   -
1.48.2.12   works
1.48.2.13   works
1.48.2.14   works
1.48.2.15   works
1.48.2.16   doesn't work



Here's what I've tested so far...in the table below, "work" means that
the host route to the destination got installed correctly and "no work"
means that it didn't.

BaseLocal Patch Result
--- --
6.2-RELEASE Unmodified  No work
6.2-RELEASE Revert nd6.c 1.48.2.{14,15} Work
6.2-STABLE  Unmodified  No work
6.2-STABLE  Revert nd6.c 1.48.2.{14,15} Work
6.2-STABLE  Revert nd6.c 1.48.2.16  No work


So strangely, this is different from my results... I can't install
6.2-RELEASE on the specific box, alas.



I'm going to write up an entry for the 6.2-RELEASE errata notes
documenting the existence of a problem and a workaround.  We still need
to figure out exactly what the right fix is.  Testing results from other
users (both 6.2-RELEASE and 6.2-STABLE) would be most welcome.


Just FYI, my initial alternative workaround was to use prefixlen 126,
e.g.:

ipv6_ifconfig_gif0="2001:7b8:2ff:146::2 prefixlen 126"

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

Re: Why does FBSD always assume it's on an 8080 CPU?

[Dimitry Andric]

Chris H. wrote:
> I've noticed building kernels, that since v. >= 5 that during
> the phase 2/3 all the lines echoed to the screen contain:
> -mno-mmx -mno-3dnow -mno-sse -mno-sse2 ...

See /usr/share/examples/etc/make.conf.


> As Pentium have been the "norm" for many years now, why aren't
> these /assumed/?

Because i486 is still the lowest common denominator, at least for 6.x.


> Default? hmmm... not as far as I can tell. Anyway, I would *greatly*
> appreciate any insight on this issue. Do I need to pollute my make.conf
> file to achive a Pentium kernel?

Yes.  Is this so horrible?

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

Re: IPv6 over gif(4) broken in 6.2-RELEASE?

[Dimitry Andric]

Bruce A. Mah wrote:
> I've convinced myself that this problem needs to be tested in isolation
> (i.e. you have complete control over both ends of the tunnel) because
> incoming packets over the tunnel cause the host route to get added
> automatically if it wasn't there already.
> 
> After reading the code and discussing this with a couple folks, I've
> managed to convince myself that 1.48.2.14 and 1.48.2.15 (and their
> analogues on HEAD) need to go away.  I've committed diffs that back
> these out, and they solve the problem for me in my testing (which I've
> done with two VMs in isolation).  The applicable revisions for nd6.c are
> 1.74 (HEAD) and 1.48.2.18 (RELENG_6).  Updating up to (or beyond) these
> revisions should clear up the problem.

Confirmed.  I've updated the machine on which I originally had this
problem to -STABLE as of today, and the problem has disappeared.

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

Re: IPv6 over gif(4) broken in 6.2-RELEASE?

[Dimitry Andric]

JINMEI Tatuya / 神明達哉 wrote:
>> Confirmed.  I've updated the machine on which I originally had this
>> problem to -STABLE as of today, and the problem has disappeared.
> 
> I thought it was also planned to be incorporated to RELENG_6_2, right?

I'm not sure if non-security related fixes are considered for release
branches.  Also, there's a workaround mentioned on the 6.2 errata page,
under "Known Issues":

http://www.freebsd.org/releases/6.2R/errata.html

Then again, it's really up to the release engineering team whether they
deem this critical enough. :)

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

Re: FreeBSD-6.2, 7.0-BETA1 boot on Lenovo X60

[Dimitry Andric]

Balgansuren Batsukh wrote:
> Last few days I try to boot FreeBSD-6.2, 7.0-BETA1 boot CD using USB
> CDROM drive on Lenovo X60.
> 
> It give kind of assembler code non-stop flow over screen.

This is a well-known issue with the USB support of some BIOSes (these
days, actually most of them).  The BIOS uses protected mode, while BTX
also does, and this clashes.

You'll need to wire up an IDE or SATA optical drive, or fiddle with PXE
to get FreeBSD installed.  On my X41, which is the predecessor to your
X60, I installed OpenBSD instead... :)

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

Re: FreeBSD-6.2, 7.0-BETA1 boot on Lenovo X60

[Dimitry Andric]

Andreas Rudisch wrote:
> or try the boot floopies:
> ftp://ftp7.freebsd.org/pub/FreeBSD/releases/i386/6.2-RELEASE/floppies/
> ftp://ftp7.freebsd.org/pub/FreeBSD/releases/i386/7.0-BETA2/floppies/

There's no floppy drive in the X series ThinkPads, so you'll end up
using an USB floppy drive.  This will probably lead to the same BTX
loader problem as with USB CD-ROM drives.  The same is probably
applicable to booting from USB sticks, and I'm not even sure FreeBSD
supports booting off those.

AFAIK the only non-PXE alternative is using the UltraBase docking
station, which has an optical drive bay connected via ATAPI.  But it's
rather expensive; here in .nl, it's about EUR 175 for the dock, and EUR
130 for the CD-RW/DVD drive (not even a DVD writer!!).
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Ok, so now what? Binary upgrade to 6.2-RELEASE fails

[Dimitry Andric]

Clint Olsen wrote:

I attempted to just do a binary upgrade, assuming that I botched the source
upgrade somehow.  After installing FreeBSD 6.2-RELEASE, I was left with a
system that would not boot (similar errors on boot as before).


Any chance you could post some of these error messages?  And if
possible, backtraces, etc?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD 7, runaway clock as guest OS on Microsoft Virtual Server

[Dimitry Andric]

On 2009-01-21 20:41, Jeffrey Williams wrote:
> I am having a problem with the system clock running excessively fast, I 
> initially tried installing 7.1 release but received a nearly continuous 
> stream of the "calcru: runtime went backward errors"

Add the following to your /boot/loader.conf file:

kern.hz="100"

I always use this setting with FreeBSD under VMware, and it solves all
these timing problems for me.  (But YMMV.)

However, I am not sure what is at fault here, VMware or FreeBSD...  I'd
guess the latter, since neither Linux nor Windows guest OSes seem to
have any such timing problems.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 7, runaway clock as guest OS on Microsoft Virtual Server

[Dimitry Andric]

On 2009-01-21 21:30, Jeffrey Williams wrote:
> Thanks for kern.hz suggestion, but according loader.conf in the 
> /boot/defaults directory, kern.hz is already set to 100, is this 
> overridden somewhere else?

Look closer, it is commented out in /boot/defaults/loader.conf.  :)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Unhappy Xorg upgrade

[Dimitry Andric]

On 2009-02-19 13:21, Stephen Clark wrote:
> (II) Loading /usr/local/lib/xorg/modules/extensions//vnc.so
> dlopen: /usr/local/lib/xorg/modules/extensions//vnc.so: Undefined symbol 
> "NumCurrentSelections"

This is a VNC problem, it uses an old API which has been removed in
newer X.org servers:

http://cgit.freedesktop.org/xorg/xserver/commit/?id=34bf308a9e66f1a2f48630a15b1802afad50ec24

See also here (and for possible workarounds):

https://bugs.launchpad.net/bugs/260815
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: dump | restore fails: unknown tape header type 1853384566

[Dimitry Andric]

On 2009-03-24 07:30, Mikhail T. wrote:
> dump a0f  - /old | restore -rf -
> [...]
>   DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009
>   DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009
>   DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009
> unknown tape header type -621260722
> abort? [yn]
> 
> Looks like a junk value somewhere... Unitialized variable or some such.

Hmm, I can't reproduce this at all; I use dump and restore quite
regularly in this way, and I have never encountered this issue (except
for the occasional 'expected file NNN, got file MMM', which is usually
harmless).

Maybe the dump output gets corrupted in some way?  (E.g. faulty RAM, or
disk?)  If you are dumping a live filesystem, could it possibly help to
add the -L option?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 32bit filesystem limitations

[Dimitry Andric]

On 2009-03-25 20:18, Barry Pederson wrote:
> Is there any reason not to skip labeling/partitioning and use da1 
> directly?  Just newfs it and mount it.  I've done this with a couple 
> large Areca arrays with no ill effect so far.

As long as you aren't going to run e.g. Windows dual-boot. ;-)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Off-by-one error in ngets() causing panic in loader(8)?

[Dimitry Andric]

On 2009-03-30 23:23, Bruce Cran wrote:
> I've noticed that if I fill the input buffer at the loader prompt on
> 7-STABLE I get panic with a guard page failure.  From what I can see
> the loader uses the ngets function in src/lib/libstand/gets.c with a
> buffer of size of 256.  If I print out the value of strlen(input) in
> interp.c I get 256. Shouldn't line 77 of gets.c be comparing (lp-buf)
> against (n-1) instead of n?

Yes, either that, or change all callers to use "sizeof buf - 1" or
similar.  However, the latter is not how the normal fgets(3) works, so
it is probably better to fix it in ngets() itself. :)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: problems with 7.2, vm_page_insert: page already inserted

[Dimitry Andric]

On 2009-04-12 02:04, Raul wrote:
> As a side note, isc-dhcp30-server port doesn't like the new jail stuff

Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=131515 for a
possible fix.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ld-elf.so.1 isn't overwritten upon making installworld

[Dimitry Andric]

On 2009-05-15 18:42, Vlad GALU wrote:
> All in subject. I could see the particular line where install is
> called on the newly built copy, but even though the system copy's file
> flags are cleared (noschg), the overwriting fails. I managed to
> overwrite it by (cp -f)-ing) the fresh copy over the old one.

Are you running in single-user mode during installworld?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ld-elf.so.1 isn't overwritten upon making installworld

[Dimitry Andric]

On 2009-05-15 22:25, Vlad GALU wrote:
>>> called on the newly built copy, but even though the system copy's file
>>> flags are cleared (noschg), the overwriting fails. I managed to
>>> overwrite it by (cp -f)-ing) the fresh copy over the old one.
>> Are you running in single-user mode during installworld?

Alright, just checking. :)  What is the exact error that you're getting?

It might also be the binary isn't changed at all, and in that case it
will *not* be updated (its Makefile uses INSTALLFLAGS=-C -b).
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: RFT: ZFS MFC

[Dimitry Andric]

On 2009-05-16 02:02, Kip Macy wrote:
> I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can.
> 
> http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/
> 
> The standard disclaimers apply. This has only been lightly tested in a
> VM. Please do not use it with data you care about at this time.

For people that would like to test this without building, e.g. to easily
install on a spare box or VM, I have put up some snapshot ISOs of this
branch, at r192269 (for i386):

http://www.andric.com/freebsd/zfs13/r192269/

Note: these don't contain a full ports collection, but enough to get a
basic system installed, or a LiveCD/DVD started.

Also, if you encounter issues with these ISOs that don't have to do with
ZFS, please don't bother Kip, but me instead. :)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: failed to set mtrr: invalid argument

[Dimitry Andric]

On 2009-05-19 08:40, Chris H wrote:
> I see. Well I'm specifically using the nv driver. Here's another
> attempt to provide the relevant info:

I could not find the error message from $subject in these logs.  Where
is it? :)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: RFT: ZFS MFC

[Dimitry Andric]

On 2009-05-19 13:33, Dmitry Morozovsky wrote:
> Would you please also post diff to RELENG_7 there?

http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2

This diff should apply with no fuzz and no rejects to RELENG_7 as of
r192386 (2009-05-19 15:33:41 UTC).  For earlier or later revisions, no
warranty. ;)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: RFT: ZFS MFC

[Dimitry Andric]

On 2009-05-19 19:41, Pete French wrote:
>> http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2
> 
> Thanks - am going to gve this a try later. Preseumably if I leave the
> pool at the revision it is currently on then I can revert back easily ?

I'll just repeat what Kip told us, "The standard disclaimers apply.
This has only been lightly tested in a VM. Please do not use it with
data you care about at this time."

That said, zpool(1M) tells:

   zpool upgrade [-V version] -a | pool ...

   Upgrades the given pool to the latest on-disk version. Once this is
   done, the pool will no longer  be  accessible  on  systems  running
   older versions of the software.

and later on:

   -V versionUpgrade  to  the specified version. If the -V flag is
 not specified, the  pool  is  upgraded  to  the  most
 recent  version.  This  option  can  only  be used to
 increase the version number, and only up to the  most
 recent version supported by this software.

E.g. you can upgrade pools to ZFS v13, but there's no way back.  If you
don't upgrade your pool, it should not destroy anything (but don't count
on it!), but you won't be able to test any new features either...


> Also, is this the version which no longer requires any tuning parameters
> in loader.conf ? That would be extermely interesting!

As far as I know, the tuning stuff still applies, especially for i386.
On my i386 test VM with 1GB RAM, vm.kmem_size is about 163 MiB without
any tuning, while vm.kmem_size_max is about 320 MiB, so you get the warning:

ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior.
 Consider tuning vm.kmem_size and vm.kmem_size_max
 in /boot/loader.conf.

So please test, and let us know your findings. :)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: RFT: ZFS MFC

[Dimitry Andric]

On 2009-05-19 22:10, Dmitry Morozovsky wrote:
> Just to be sure: is the patch based on sys/ hierarchy, and does not touch 
> others (like sbin/)?

No, it touches stuff in cddl/ too, so you need to build the world.  Be
sure to use -E with patch, to cleanup emptied files.  E.g.:

patch -d /usr/src -p1 -f -F0 -E -i /path/to/zfs-mfc.patch
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: RFT: ZFS MFC

[Dimitry Andric]

On 2009-05-19 23:08, Dmitry Morozovsky wrote:
> After cleaning /usr/obj and buildworld in single thread I got
> 
> /usr/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris/sys/acl.h:35: 
> error: conflicting types for 'aclent_t'
> /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys/acl.h:43:
>  
> error: previous declaration of 'aclent_t' was here

You probably didn't use -E with patch, the following files can be
removed manually afterwards:

sys/cddl/compat/opensolaris/sys/acl.h
sys/cddl/contrib/opensolaris/common/atomic/amd64/atomic.S
sys/cddl/contrib/opensolaris/common/atomic/i386/atomic.S
sys/cddl/contrib/opensolaris/common/atomic/ia64/atomic.S
sys/cddl/contrib/opensolaris/common/atomic/sparc64/atomic.S
sys/cddl/contrib/opensolaris/uts/common/rpc/xdr.c
sys/cddl/contrib/opensolaris/uts/common/rpc/xdr_array.c
sys/cddl/contrib/opensolaris/uts/common/rpc/xdr_mem.c
sys/cddl/contrib/opensolaris/uts/common/sys/vfs.h
sys/cddl/contrib/opensolaris/uts/common/zmod/crc32.c

My copy is currently still buildworlding, and hasn't failed yet...
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: RFT: ZFS MFC

[Dimitry Andric]

On 2009-05-19 23:57, Dmitry Morozovsky wrote:
> ... but then again, on `build all'' phase, I got
> 
> ===> cddl/sbin/zpool (all)
> cc -O2 -fno-strict-aliasing -pipe -march=athlon-mp 
> -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libzpool/common
>  
> -I/usr/src/cddl/sbin/zpool/../../../cddl/compat/opensolaris/include 
> -I/usr/src/cddl/sbin/zpool/../../../cddl/compat/opensolaris/lib/libumem 
> -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/compat/opensolaris 
> -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/head 
> -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libuutil/common
>  
> -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libumem/common
>  
> -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libzfs/common
>  
> -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libnvpair 
> -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/common/zfs 
> -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common 
> -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs
>  
> -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys
>  
> -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas  -o zpool zpool_main.o 
> zpool_vdev.o zpool_iter.o zpool_util.o -lavl -lzfs -lgeom -lbsdxml -lsbuf  
> -lm 
> -lnvpair -luutil -lutil
> zpool_main.o(.text+0x61ff): In function `zpool_do_create':
> : undefined reference to `zfs_allocatable_devs'
> *** Error code 1

FWIW, I just did a full buildworld, kernel, reboot, installworld dance,
there were no errors.  You may possibly have some cruft left in obj, or
you could zap your src tree and start fresh? :)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: error building zfsboot

[Dimitry Andric]

On 2009-05-26 10:20, Goran Lowkrantz wrote:
> On a system cvsuped Tue May 26 08:30 CEST 2009 and only 
> LOADER_ZFS_SUPPORT=yes in the make.conf, I get the following error:
...
> btxld: zfsboot.ldr: Invalid argument
...
> Looking in the directory, zfsboot.ldr is empty:

Your CVSup mirror may be out of date, this was fixed as of r192697.

Since you are using CVS and not Subversion, make sure you have
usr.sbin/btxld/btxld.c revision 1.10.2.1.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ZFS pool from current

[Dimitry Andric]

On 2009-06-17 16:09, Nenhum_de_Nos wrote:
> And for virtualbox on amd64 purposes I want to run 7.2R or STABLE to use
> VT-x and amd64 vm's under vbox. will I have to make anything, or it will
> just work ?
> 
> Kip Macy created a branch were there is the new zfs code, but I didn't get
> it if it is in the main sources or if I need to fetch any especial code.

Kip merged the ZFS v13 support to -STABLE just last month.  It seems to
work okay for most people, but be sure to read the UPDATING file,
especially if you are upgrading existing pools.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: What is /boot/kernel/*.symbols?

[Dimitry Andric]

On 2009-07-03 16:25, Patrick M. Hausen wrote:
> On a current server with 512 MB /, the filesystem is at
> 97% after installing a new kernel twice. Can I get rid of
> these files somehow or are they necessary, in which case
> I will need way bigger root filesystems?
> 
> I mean, get rid automatically and never install them again.
> I know the chflags and rm commands ;-) But then the question
> of they are needed is still open.

You can find this in /usr/src/UPDATING:

20060118:
This actually occured some time ago, but installing the kernel
now also installs a bunch of symbol files for the kernel modules.
This increases the size of /boot/kernel to about 67Mbytes. You
will need twice this if you will eventually back this up to kernel.old
on your next install.
If you have a shortage of room in your root partition, you should add
-DINSTALL_NODEBUG to your make arguments or add INSTALL_NODEBUG="yes"
to your /etc/make.conf.

However, you should consider increasing the size of your root
partition, if possible.  It can be extremely handy to have symbol files
available whenever there's a crash.  :)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: What is /boot/kernel/*.symbols?

[Dimitry Andric]

On 2009-07-03 16:41, Patrick M. Hausen wrote:
> But I thought, they were in the kernel itself?
> 
> %file /boot/kernel/kernel
> /boot/kernel/kernel: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), 
> dynamically linked (uses shared libs), not stripped
> 
> "not stripped" - i.e. "with debug symbols". Wrong? Since when?

Well, only the debug symbols have been stripped, not any others.  If you
look in /usr/src/sys/conf/kern.post.mk, you will see this fragment:

${KERNEL_KO}: ${FULLKERNEL} ${KERNEL_KO}.symbols
${OBJCOPY} --strip-debug --add-gnu-debuglink=${KERNEL_KO}.symbols\
${FULLKERNEL} ${.TARGET}
${KERNEL_KO}.symbols: ${FULLKERNEL}
${OBJCOPY} --only-keep-debug ${FULLKERNEL} ${.TARGET}

E.g. the debug stuff is put into the .symbols files.  The kernel itself
still contains the function and data names, though:

$ objdump -t /boot/kernel/kernel

/boot/kernel/kernel: file format elf32-i386-freebsd

SYMBOL TABLE:
c092de00 l   .data   tmpstk
c092de58 l   .data   physfree
c092de64 l   .data   proc0uarea
[...]

If you want to build absolutely without any symbols whatsover, remove
the "makeoptions DEBUG=-g" line from your kernel config file.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: What is /boot/kernel/*.symbols?

[Dimitry Andric]

On 2009-07-06 09:42, Patrick M. Hausen wrote:
>> #define ROOT_DEFAULT_SIZE   512
> 
> IMHO it is not. If you install a kernel with *.symbols present
> twice (i.e. kernel and kernel.old contain symbol files), your
> root partition will be > 95% full.

I'm not sure how you arrive at this number; even with -CURRENT (on i386,
with all debug symbols), I could store about 4 complete kernels on such
a filesystem:

$ du -hs /boot/kernel*
122M/boot/kernel
122M/boot/kernel.20090629a
121M/boot/kernel.20090630a
122M/boot/kernel.20090702a
121M/boot/kernel.20090703a

All other files on my root filesystem use up an additional ~25 MiB, so
in practice, it would be limited to 3 kernels, with more than enough
breathing room.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: What is /boot/kernel/*.symbols?

[Dimitry Andric]

On 2009-07-06 10:41, Dan Naumov wrote:
> atom# uname -a
> FreeBSD atom.localdomain 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #0: Tue
> Jun  9 18:02:21 UTC 2009
> r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
> 
> atom# du -hs /boot/kernel*
> 205M/boot/kernel

Right, so it's a lot bigger on amd64.  I guess those 64-bit pointers
aren't entirely free. :)

So indeed, on amd64 and possibly some other 'big' architectures (ia64?),
cranking the default root filesystem size to e.g. 1024M would be nice.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: What is /boot/kernel/*.symbols?

[Dimitry Andric]

On 2009-07-06 11:39, Ruben de Groot wrote:
>>> r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
>>>
>>> atom# du -hs /boot/kernel*
>>> 205M/boot/kernel
>>
>> Right, so it's a lot bigger on amd64.  I guess those 64-bit pointers
>> aren't entirely free. :)
> 
> I'm not sure where the size difference comes from. I have some sparc64
> systems running -current with symbols and the size of /boot/kernel is
> more comparable to i386, even with the 8-byte pointer size:
> 
>> uname -p
> sparc64
>> du -sk /boot/kernel
> 137918  /boot/kernel

It looks like on amd64, the kernel is compiled with optimization flags:

  -O2 -frename-registers -pipe -fno-strict-aliasing

by default, while on i386, they are just:

  -O -pipe

Maybe this accounts for the huge difference?  Does -O2 do a lot more
inlining?

In any case, it's a weird inconstency, if you ask me.  But it's
intentional, as /usr/src/sys/conf/kern.pre.mk says:

. if ${MACHINE_ARCH} == "amd64"
COPTFLAGS?=-O2 -frename-registers -pipe
. else
COPTFLAGS?=${_MINUS_O} -pipe
. endif

where ${_MINUS_O} is by default just "-O", since DEBUG is enabled...
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: hw.realmem in stable.

[Dimitry Andric]

On 2009-07-06 22:57, Amza Marian wrote:
> I have the kernel compiled with PAE option but anyway, the system report 
> only 600 MB ram
...
> hw.realmem: 603979776
...
> lsg ~ # grep memory /var/run/dmesg.boot
> real memory  = 4898947072 (4672 MB)
> avail memory = 4117958656 (3927 MB)

This looks like a wraparound issue, your realmem doesn't fit into a
32-bit integer:

4,672 MB - 2^32 = 4,898,947,072 - 4,294,967,296 = 603,979,776
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ZFS - thanks

[Dimitry Andric]

On 2009-07-11 10:40, Peter Jeremy wrote:
> On 2009-Jul-09 15:39:35 +0300, Dan Naumov  wrote:
>> A single 40 disk raidz (DO NOT DO THIS) will have 40 disks total, 39
>> disks worth of space and will definately explode on you sooner rather
>> than later (probably on the first import, export or scrub).
> 
> Can you provide a reference for this statement.  AFAIK, the only
> reason for the upper recommended limit of 9 disks is performance.

The more disks you use in one RAID set, the higher the probability that
more than one disk will fail at the same time.  An interesting read can
be found here: http://blogs.zdnet.com/storage/?p=162
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zfs on gmirror slice

[Dimitry Andric]

On 2009-09-02 10:27, Mark Stapper wrote:
> self-healing sounds very nice, but with mirrorring you have data on two
> discs, so in that case there no "healing" involved, it's just
> checksumming and reading the non-corrupted copy.
> From the gmirror manpage: "All operations like failure detection, stale
> component detection, rebuild of stale components, etc. are also done
> automatically."
> This would indicate the same functionality, with a much less fancy name.

Not really. ZFS can checksum the actual file data, while gmirror can
only detect errors it gets told about by the underlying disk.  E.g. if
the disk silently corrupts data, you will never know about it.

Also, if gmirror needs to resynchronize, it must resynchronize the whole
disk, since it can't detect which specific parts of it were corrupted.
ZFS synchronizes on demand.

There are also some other advantages to ZFS mirroring, see pages 15 and
further of these slides:

http://www.opensolaris.org/os/community/zfs/docs/zfs_last.pdf
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zfs won't automount

[Dimitry Andric]

On 2009-09-02 18:55, Lisa Besko wrote:
> I have a system that has a simple zfs raid 0 volume on it and it will 
> now mount when the system boots.  After the system is up I can run 
> /etc/rc.d/zfs start and it's fine.  I don't see any errors in the log 
> file other than the ZFS is experimental in FreeBSD message.  I'm running 
> FreeBSD 7.2 stable.  I have zfs_enable="YES" in the rc.conf file.  Am I 
> missing something?

What do "zpool list" and "zfs list" say?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zfs won't automount

[Dimitry Andric]

On 2009-09-03 19:28, Edho P Arief wrote:
> fastest way would be adding entry
> 
> sniffer /sniffer zfs rw 0 0
> 
> to /etc/fstab

No, that is not the way you should do it with ZFS.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Upgrade FreeBSD 7.1 to 7.2

[Dimitry Andric]

On 2009-09-09 14:25, Michael Sperber wrote:
>> If you rely on a serial console, I
>> would recommend first switching 7.2 to using uart
...>
> Could you briefly elaborate on how that's done with 7.x?  I.e. is
> changing device.hints and /etc/ttys enough (what changes?), or do I need
> to recompile the kernel?

You also need to remove device sio from your kernel configuration and
recompile.  If you have both sio and uart in your kernel (the default on
7.x IIRC), sio will take precedence.

N.B: please exercise caution when doing this to a server in a colo 1
km away. :)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Avahi compilation help needed

[Dimitry Andric]

On 2009-09-10 14:06, Sagara Wijetunga wrote:
> I'm trying to compile Avahi-0.6.25 (http://avahi.org/) on FreeBSD 7.2 
> (i386) [in fact, on Tomahawk Desktop]. It develops compilation errors. 

Any reason why you don't use the net/avahi port instead?  This will save
you most compilation and installation headaches.  
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Avahi compilation help needed

[Dimitry Andric]

On 2009-09-10 16:39, Sagara Wijetunga wrote:
> Tomahawk Desktop uses FreeBSD sources, it is not based on the FreeBSD 
> distribution.

Please contact the Tomahawk Desktop mailing lists then. :)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.0 rc.d scripts less verbose?

[Dimitry Andric]

On 2009-09-15 16:37, Ronald Klop wrote:
> Since I run 8.0 the rc.d scripts are less verbose. I have some problems  
> with them, but the default output gives me no information anymore.
> 
> In the 8.0-TODO wiki there is a mention about verbosity of the rc.d  
> scripts at the bottom. Is there a way for me to increase the verbosity?

Nope, this was removed, apparently.  A pity, since this was very useful
information during boot time.  However, setting rc_debug will give you
enormous gobs of useless info (unless you're debugging rc scripts), and
rc_info doesn't seem to add much anymore, if anything.

To restore the old behaviour, apply the following patch (I have this in
my local repository for ages now):


Index: etc/rc.subr
===
--- etc/rc.subr (revision 196888)
+++ etc/rc.subr (working copy)
@@ -680,7 +680,7 @@ run_rc_command()
 
# setup the full command to run
#
-   [ -z "${rc_quiet}" ] && echo "Starting ${name}."
+   echo "Starting ${name}."
if [ -n "$_chroot" ]; then
_doit="\
 ${_nice:+nice -n $_nice }\
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.0 rc.d scripts less verbose?

[Dimitry Andric]

On 2009-09-16 09:54, Cezary Morga wrote:
> Wouldn't it be easier to set rc_quiet to zero-length value, like 
> rc_quiet=""?

No, rc_quiet is not user-settable (at least not from /etc/rc.conf).
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.0 rc.d scripts less verbose?

[Dimitry Andric]

On 2009-09-17 09:17, Oliver Fromme wrote:
> My feeling is that hiding all of the "starting" messages
> is a regression that needs to be fixed.  I cannot think
> of a good reason why they should be hidden, but there
> are certainly good reasons to display them.

The commit that introduced this, r179946, has this log message:


Move the diagnostic output when the rc.subr(8) glue automatically starts a
service behind $rc_quiet. Instead, output a warning if the pre-command
routine or the command itself failed. Arguably, it's more useful to know when
a command failed to start than it is to have an endless list of
"Starting " lines[1].

[1] - This change actually helped me to discover a bug in rc.d/{lockd,statd}
  (fixed in r179941) that used to fail silently before.


It is really a matter of taste, I guess.  There is something to be said
for eliminating verbosity, in order to make real errors more visible.

On the other hand, if one of your startup rc scripts hangs (for whatever
reason), it is nice to have an approximate idea which one it is. :)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Console has no name?

[Dimitry Andric]

Hi,

Somewhere between r198312 and r198702 I started getting this message
during boot, on a machine using serial console:

WARNING: console at 0xc093cea0 has no name

This is just before the copyright banner of the kernel.  Does anybody
have an idea what might cause this, before I start digging? :)

The machine has /boot.config with just "-P", and no console-related
entries in /boot/loader.conf.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Console has no name?

[Dimitry Andric]

On 2009-10-31 14:14, Dimitry Andric wrote:
> Somewhere between r198312 and r198702 I started getting this message
> during boot, on a machine using serial console:
> 
> WARNING: console at 0xc093cea0 has no name

Okay, this seems to be caused by r198655, which is an MFC of r197570,
where experimental support for USB serial console was added.

However, the consdev::cn_name field is never initialized in
usb_serial.c, whereas this does happen in other console drivers.

There doesn't seem to be a consensus whether this field needs to be
initialized in the _cnprobe() or _cninit() functions: I count 9 instances
of initialization in the former, and 3 in the latter.  Is there a
preferred way?

Since _cnprobe seems more popular, I propose the following fix:

Index: sys/dev/usb/serial/usb_serial.c
===
--- sys/dev/usb/serial/usb_serial.c (revision 198702)
+++ sys/dev/usb/serial/usb_serial.c (working copy)
@@ -1301,6 +1301,7 @@ static void
 ucom_cnprobe(struct consdev  *cp)
 {
cp->cn_pri = CN_NORMAL;
+   strlcpy(cp->cn_name, "ucom", sizeof cp->cn_name);
 }
 
 static void
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

6.0-BETA2 through 4: BTX halted?

[Dimitry Andric]

I've been trying the 6.0 BETA's on several machines, and I've seen a
lot of them crashing during the BTX loader from CD.  Usually it just
fills up the screen endlessly with scrolling BTX exception messages,
which alas makes these messages unreadable (and thus no hand copying
possible!).   This can only be stopped by resetting the machine.

Today I tried 6.0-BETA2 and BETA4 on my new ThinkPad X41, with an
attached USB DVD-RW drive, and I got a similar error.  However, in
some cases it keeps on printing exception messages, just as on the
other boxes, but in other cases (especially when the CD is still
spinning up) you get 1 exception message, and then the machine simply
reboots.

So without further ado, here's my hand copying work:

CD Loader 1.2
int=000d  err=001a  efl=00030246  eip=1a46
eax=220050d7  ebx=0002  ecx=1000  edx=40f7
esi=061c  edi=  ebp=061c  esp=0614
cs=0e01  ds=dcf1  es=fs=0010  gs=  ss=dcf1
cs:eip=cc 7c bd 8b 45 d8 66 8b-78 30 e9 30 ff ff ff 8d
   76 00 31 c0 8d 65 f4 5b-5e 5f c9 c3 b8 ab aa aa
ss:esp=50 94 e7 e2 46 02 36 a2-18 00 40 0c 34 00 00 dc
   00 10 00 00 ff ff 8b 5b-21 00 00 00 00 00 01 00
BTX halted

Looks like a general protection fault, and I'm going to check the BTX
code to see if this occurs somewhere in there.

Anyone also seen this specific exception message?  Most other OS
install CD's (e.g. Linux, Windows) I throw at this machine boot
without problems, btw.

P.S: I just tried 5.4-RELEASE on the same X41, and BTX crashes there
too... :(


pgpS1Vl206pXu.pgp
Description: PGP signature

Re: 6.0-BETA2 through 4: BTX halted?

[Dimitry Andric]

On 2005-09-17 at 06:45:51 Derek wrote:

>> P.S: I just tried 5.4-RELEASE on the same X41, and BTX crashes there
>> too... :(

> I've seen these identical systems on earlier versions, and documented as
> much as I could in:

> http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/72960

Actually, it's more like this PR, since I'm also using an external USB
DVD-RW drive:

  http://www.freebsd.org/cgi/query-pr.cgi?pr=85257

Possibly the BIOS does something nasty (i.e. using protected mode) to
support booting off USB disks, which causes BTX' exceptions.

OTOH, neither OpenBSD's, nor several Linux distro's CD loaders seem to
have problems with it.

Last note: I've also tried the 6.0-BETA5 bootonly ISO, giving exactly
the same result.  So no FreeBSD on this laptop for me... :(


pgpAREi8S8FGX.pgp
Description: PGP signature

Re: FreeBSD 6 Released BTX loader issue

[Dimitry Andric]

[redirecting to -stable, where this belongs]

lee sheng wrote:
> I'm trying to have clean install FreeBSD 6.0 released in my X41 thinkpad by
> using the cd, however I have problem while booting it in thinkpad X41 when I
> load it using usb combo drive. The BTX loader keeps looping and halted
> someway and I have actually seen this report from previous post but it is
> not yet been fixed even till the FreeBSD 6.0 release.

Indeed, FreeBSD's BTX loader doesn't seem to support any USB devices.
 It also dies while booting from a USB stick, for example.


> I would like to know the status and what's actual problem or is there any
> workaround.

In the end I gave up trying to install FreeBSD on my X41, after having
tried all kinds of things.  Now it runs Linux and OpenBSD without a
hitch. ;)

Then again, I didn't have a UltraBase docking station, which seems to
contain an ATAPI DVD/CD station.  You might be able to bootstrap with
that.



signature.asc
Description: OpenPGP digital signature

Re: OT: Failure notices from blogger.com

[Dimitry Andric]

Michael Nottebrock wrote:
> I recently started to get failure notices from [EMAIL PROTECTED] when I 
> post on the freebsd-stable mailing list.

Same here.


> What is that all about? Is somebody redirecting all mail on the list to a 
> blog 
> via post-by-mail? 

I guess something auto-posts FreeBSD mailing list posts to some blog
hosted at blogger.com.  I've simply mailed [EMAIL PROTECTED] with
a complaint, since that seems to be the only address related to
blogger.com that doesn't bounce. :)

IMHO they should never auto-generate error or bounce reports in
response to bulk email, so that's what I told them in my complaint.
You may want to join in...



signature.asc
Description: OpenPGP digital signature

Re: OT: Failure notices from blogger.com

[Dimitry Andric]

Dimitry Andric wrote:
> Michael Nottebrock wrote:
>> What is that all about? Is somebody redirecting all mail on the list to a 
>> blog 
>> via post-by-mail? 
> I guess something auto-posts FreeBSD mailing list posts to some blog
> hosted at blogger.com.

I found this in the blogger.com FAQ: "The Mail-to-Blogger feature
turns any email account into a blog-posting application. In Settings |
Email you can create a Mail-to-Blogger address which you will use to
send posts via email to your blog"

http://help.blogger.com/bin/answer.py?answer=135&topic=38

So someone probably subscribed one or more @blogger.com addresses to
this, and other FreeBSD mailing lists.

If this mail-to-blogger stuff doesn't work properly, would the list
admin(s) please be so kind to unsubscribe these blogger.com users from
all FreeBSD mailing lists?  IMHO these unsolicited "error" messages
are just as bad as "out of office" spam.



signature.asc
Description: OpenPGP digital signature

Re: DHCP client error: domain_not_set.invalid

[Dimitry Andric]

Mark Andrews wrote:
>   What would be really interesting to know is what they expect
>   the customers to find using this suffix.
> 
>   My bet is that this really is just a configuration error on
>   their part.

As is often said: "Never attribute to malice what can adequately be
explained by incompetence." :)  And I'm afraid that's just the case here.



signature.asc
Description: OpenPGP digital signature

Re: Problems compiling latest cvs

[Dimitry Andric]

Kevin Lamothe wrote:
> In file included from
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_alloc.cc:37:
> 
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20:
> unwind.h: No such file or directory
--snip--
> The contents of my make.conf
> 
> CFLAGS=-O2 -pipe
> CXXFLAGS=-O2 -pipe

Don't assign to CXXFLAGS with "=", as /usr/share/examples/etc/make.conf
tells you:

# CXXFLAGS controls the compiler settings used when compiling C++ code.
# Note that CXXFLAGS is initially set to the value of CFLAGS.  If you wish
# to add to CXXFLAGS value, "+=" must be used rather than "=".  Using "="
# alone will remove the often needed contents of CFLAGS from CXXFLAGS.




signature.asc
Description: OpenPGP digital signature

RELENG_6: serial console drops back from 115200 to 9600 baud

[Dimitry Andric]

Hi,

I believe this MFC commit:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/libi386/comconsole.c?rev=1.10.10.1&content-type=text/x-cvsweb-markup
broke the speed-setting of the serial console at boot time, for RELENG_6.

At least for me, it doesn't set the speed to 115200 (as specified in
make.conf) anymore, it always stays at 9600, even when I put
comconsole_speed=115200 in loader.conf.

I noticed this, when I upgraded from 6.0-STABLE built around december
last year, to 6.1-PRERELEASE from last week.  The serial console on this
particular machine had been working flawlessly for years now...

There's a new comment added by the commit in this file that says:

/*
 * Assume that the speed was set by an earlier boot loader if
 * comconsole is already the preferred console.
 */

whereas in the previous version it was set (hardcoded) to COMSPEED,
which in its turn came from BOOT_COMCONSOLE_SPEED in
boot/i386/libi386/Makefile.

Anyone know of a way to restore the old behaviour?  I'll experiment here
with reverting the comconsole.c file to the previous version, to see if
that helps, but a permanent solution would be better. :)

Cheers,
Dimitry




signature.asc
Description: OpenPGP digital signature

Re: RELENG_6: serial console drops back from 115200 to 9600 baud

[Dimitry Andric]

Dimitry Andric wrote:
> whereas in the previous version it was set (hardcoded) to COMSPEED,
> which in its turn came from BOOT_COMCONSOLE_SPEED in
> boot/i386/libi386/Makefile.
> 
> Anyone know of a way to restore the old behaviour?  I'll experiment here
> with reverting the comconsole.c file to the previous version, to see if
> that helps, but a permanent solution would be better. :)

Confirmed, putting back rev 1.10 of comconsole.c restores the old
behaviour.  My serial console runs at 115200 baud again.

I still don't get why comconsole_speed in /boot/loader.conf didn't work
with the newer revision, though...




signature.asc
Description: OpenPGP digital signature

Re: RELENG_6: serial console drops back from 115200 to 9600 baud

[Dimitry Andric]

Ed Maste wrote:
> The way this is supposed to work is that you can put -S
> in /boot.config, which gets used by boot2, and the loader then
> detects that the serial console is already in use and defaults
> to the existing speed.

Ah, I didn't try that yet.  However, I would expect that the
BOOT_COMCONSOLE_SPEED override in /etc/make.conf would simply continue
to work as it had.


> comconsole_speed="115200" in loader.conf should override it
> if you don't want to replace boot2 or change /boot.config.

Yes, I've tried this, but it didn't work, or maybe I just didn't try
hard enough. :)  I'll try it again with the 1.10.10.1 rev of comconsole.c.




signature.asc
Description: OpenPGP digital signature

Re: RELENG_6: serial console drops back from 115200 to 9600 baud

[Dimitry Andric]

Ed Maste wrote:
> What's in your /boot.config?

In my case, I use -P, because I usually don't have a keyboard hooked up,
but ocasionally do use it.  Additionally, I had console="comconsole" in
my /boot/loader.conf.  However, commenting that out doesn't help either.

I guess the -P option causes the console variable to be set too?  In
that case comc_probe might pick it up, and never change the speed from
what the BIOS configured.  (Note that I've never used boot0sio, and
AFAICs the 'normal' boot0 doesn't mess with the serial port speed.)


> Are your bootblocks from the 6.1 beta as well, or from a previous install?

I never actively reinstalled them, except of course for running
installworld.  I've always assumed installworld would take care of that,
and I really would be amazed if it didn't. :)




signature.asc
Description: OpenPGP digital signature

Re: RELENG_6: serial console drops back from 115200 to 9600 baud

[Dimitry Andric]

Ian Dowse wrote:
> The problem may be that your boot blocks were compiled with
> BOOT_COMCONSOLE_SPEED set to 9600. Try reinstalling them with e.g.
> `disklabel -B ad0s1' (make sure you get the right device name -
> it should be the slice that you boot from).

Okay, but why did 4.x through 5.x through 6.x (these have all been on
this particular machine) always boot with 115200 until now? :)

Anyway, I also thought that installworld would take care of installing
any updated boot blocks, if necessary.  I'll manually install them and
see what I end up with.


> Previously both /boot/loader and the boot blocks would override the
> serial port speed according to BOOT_COMCONSOLE_SPEED, but I believe
> that since the recent change, loader will assume that if the boot
> blocks requested a serial console, then they will have already set
> up the correct speed.

Ah, but notice that I didn't use boot0sio, but the regular boot0.  It
seems the serial port speed setting is compiled out in the latter
version.  Hence the port speed will be the BIOS default, which I alas
can't change; it's always 9600n1.




signature.asc
Description: OpenPGP digital signature

Re: RELENG_6: serial console drops back from 115200 to 9600 baud

[Dimitry Andric]

Ian Dowse wrote:
>> Okay, but why did 4.x through 5.x through 6.x (these have all been on
>> this particular machine) always boot with 115200 until now? :)

> They probably used 9600 for the boot blocks, and then switched to
> 115200 when /boot/loader started, so you didn't notice. Now the
> settings from the boot blocks get used by /boot/loader.

Ah, but this still means that /boot/loader used to use a hardcoded
default specified in /etc/make.conf, and now it doesn't honor that anymore.

There should at least be a notice in UPDATING, e.g. "don't forget to set
comconsole_speed in your loader.conf, or your serial console won't work
anymore after upgrading."  It would probably save some people a drive to
the colocation facility... ;)


> Boot blocks need to be installed manually - installworld installs
> the boot blocks as files in /boot/boot{1,2}, but when booting, it
> is the boot blocks in the first 8k of the slice that are used, not
> the /boot/boot{1,2} files.

Okay.  I still think it would be wiser to just reinstall them during
installworld, just to be sure there's no incompatibilities...




signature.asc
Description: OpenPGP digital signature

Re: RELENG_6: serial console drops back from 115200 to 9600 baud

[Dimitry Andric]

Ed Maste wrote:
>> Okay, but why did 4.x through 5.x through 6.x (these have all been on
>> this particular machine) always boot with 115200 until now? :)

> Because now the loader has new behaviour of using the existing speed
> if the previous stage indicates a serial port is in use, instead
> of blindly jamming in a compile-time setting.

Fine, but please be aware that this new behaviour violates POLA, at
least without a stern notice in UPDATING. :)  My idea about hard coded
defaults has always been that they are followed, not ignored...


> comconsole_speed= in /boot/loader.conf
> existing speed, if comconsole is already set by previous stage
> BOOT_COMCONSOLE_SPEED compile time default

Well, the last item will simply never be hit, since there is ALWAYS a
previous stage, isn't there?  So then you might as well remove the
compile time default.  Or at least make clear that the compile time
default only applies to boot[12], and not the loader.


>> Anyway, I also thought that installworld would take care of installing
>> any updated boot blocks, if necessary.  I'll manually install them and
>> see what I end up with.
> 
> It doesn't seem that way.  They'll be placed in /boot, but not
> in the mbr or slice I think.

Indeed, as Ian explained.  FYI, I've just installed new boot blocks with
a configured BOOT_COMCONSOLE_SPEED, commented out the console= and
comconsole_speed= entries in loader.conf, and this works as expected now.

However, please keep in mind that this might hit non-binary upgraders
who use serial consoles, e.g. people with remote boxes in faraway
places.  They should be warned to either upgrade their bootblocks
manually, or set the speed directives in loader.conf.





signature.asc
Description: OpenPGP digital signature

Re: RELENG_6: serial console drops back from 115200 to 9600 baud

[Dimitry Andric]

Ian Dowse wrote:
> The problem may be that your boot blocks were compiled with
> BOOT_COMCONSOLE_SPEED set to 9600. Try reinstalling them with e.g.
> `disklabel -B ad0s1' (make sure you get the right device name -
> it should be the slice that you boot from).

Argh, shouldn't have done this without thinking on a dangerously
dedicated disk. :)  But after recovering the partition table with fdisk,
the new boot blocks work as expected, thanks.


> Previously both /boot/loader and the boot blocks would override the
> serial port speed according to BOOT_COMCONSOLE_SPEED, but I believe
> that since the recent change, loader will assume that if the boot
> blocks requested a serial console, then they will have already set
> up the correct speed.

Yes, so people should be urged to upgrade their boot blocks, in case of
a non-binary upgrade.  (I assume that a binary upgrade WILL install
fresh boot blocks?)




signature.asc
Description: OpenPGP digital signature

Re: RELENG_6: serial console drops back from 115200 to 9600 baud

[Dimitry Andric]

Ed Maste wrote:
> So I suspect that the following happens when you boot:
> 
> - your BIOS sets the serial port to 9600

Yes.

> - boot0 does nothing with the serial pot

I'm using 'dangerously dedicated' disks, so it's only boot[12] that is used.

> - boot1/2 reads the -P in /boot.config and detects no keyboard, and
>   then sets the serial port to 9600 and the console to comconsole

Indeed, I never got the "/boot.config: -P" message on the serial console
before.  Now I get it, using updated boot blocks.

> - the loader detects that the serial port is enabled and is already
>   set to 9600

> Thus, I'm not surprised that you get a 9600 baud console without
> an rc.conf setting.  The thing that concerns me is your report that
> the console does not run at 115200 even if /boot/loader.conf
> contains comconsole_speed="115200".

This turns out to be an error on my part, sorry to have you worried. :)
I'd accidentally put "console_speed=115200" in loader.conf.  With
"comconsole_speed=115200" and 9600 baud boot blocks, it works okay,
although you don't see any of the boot[12] messages, of course.

That's why installing 115200 baud boot blocks is still the better
solution for me; my BIOS doesn't have any possibility to set the COM
port speeds...




signature.asc
Description: OpenPGP digital signature

Re: RELENG_6: serial console drops back from 115200 to 9600 baud

[Dimitry Andric]

Ruslan Ermilov wrote:
>> That's why installing 115200 baud boot blocks is still the better
>> solution for me; my BIOS doesn't have any possibility to set the COM
>> port speeds...
> The best for you would be to add -S115200 in /boot.config, after
> reinstalling new boot blocks (bsdlabel -B), and throw everything
> else that's related from make.conf and loader.conf.

I'll try this out, but I still usually like hardcoded defaults. :)




signature.asc
Description: OpenPGP digital signature

Re: Matlab

[Dimitry Andric]

Albert Shih wrote:
> /usr/local/matlab/bin/matlab: line 1: /lib/libc.so.6: cannot execute binary 
> file
> /usr/local/matlab-14/bin/glnx86/MATLAB: error while loading shared libraries: 
> /usr/lib/libtermcap.so: ELF file OS ABI invalid
> 
> But I've compile the kernel with linux option and maple (other soft using
> linux too) work fine.

Do you have "linux_enable=YES" in your rc.conf?




signature.asc
Description: OpenPGP digital signature

Re: loader_color="YES"

[Dimitry Andric]

Nikolas Britton wrote:
> What happen to 'loader_color="YES"' if FreeBSD 6.x?
> 
> If you put this in loader.conf it would make a color daemon in the boot menu.

Read /etc/defaults/loader.conf:

loader_logo="fbsdbw"   # Desired logo: fbsdbw, beastiebw, beastie, none

e.g. "beastie" means the color version.




signature.asc
Description: OpenPGP digital signature

Re: Is mount_smbfs broken in 6.1-PRERELEASE?

[Dimitry Andric]

Nikolas Britton wrote:
> "mount_smbfs: unable to open connection: syserr = Authentication error"

What does your syslog say? Maybe you can check this PR:

http://www.freebsd.org/cgi/query-pr.cgi?pr=93458


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

Re: Your Online E-mail Address Change

[Dimitry Andric]

David Rhodus wrote:
> How does this work ?
> 
> client# ping 3645219926
> PING 3645219926 (217.69.164.86): 56 data bytes

Read man inet_aton(3), section "INTERNET ADDRESSES".
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 4.11 snapshots?

[Dimitry Andric]

Dmitry Pryanishnikov wrote:
>   Well, have you seen my simple performance benchmarking RELENG_4 vs 6?
> IMHO it mimics quote common usage pattern: it just downloads a large file
> with 10Mbps rate and stores it on UFS filesystem. On the same hardware
> (i386 uniprocessor Celeron-333 system with 128Mb RAM and fast SAMSUNG
> SP0802N
> HDD using UDMA33) under the same conditions, using more optimal config
> (INVARIANTS removed) RELENG_6 (and 5) _still_ uses >= 50% of CPU time
> for (Intr+Sys), while RELENG_4 doesn't use more than 28% for them.

Just as a test for RELENG_6, could you try setting kern.hz="100" in your
loader.conf, and repeating your tests?  I'm just guessing, but maybe the
higher interrupt rate is a bit too much for an old Celeron... :)

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

Re: acpi: bad write to port

[Dimitry Andric]

Oliver Fromme wrote:
> acpi: bad write to port 0x080 (32), val ...
...
> Do I have to worry?  So far it doesn't seem to cause any
> harm.

It's probably just a buggy BIOS, see:
http://lists.freebsd.org/pipermail/freebsd-acpi/2006-June/002890.html
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re[2]: SMBFS panic: malloc: wrong bucket (was: 4.3-20010721-STABLE)

[Dimitry Andric]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2001-08-03 at 17:04:37 Boris Popov wrote:

BP> Please try the attached patch. It fixes a nasty buffer overflow
BP> which may cause this panic.

Okay, this patch seems to solve the panic problem for me. On the
previously crashing box, I cvsup'd today (to 4.4-PRERELEASE) and
rebuilt everything, including the kernel with your patch, and the
smbfs-1.4.1 port. Since then, I haven't been able to get it to crash
anymore. :) (Keeping my fingers crossed.)

I have some other remarks, though, if you don't mind:

1. When I mount_smbfs(8) a share, the mountpoint is owned by
root:wheel and mode 755 by default. However, as a normal user I can
_create_ files in this mountpoint, but not delete them! I would
suppose that a normal user doesn't have write access with mode 755?

2. I searched for an answer to this phenomenon in the mount_smbfs(8)
manpage, and it says with the -M option: "Assign access rights to the
newly created connection.  See nsmb(8) for theory."  However, there's
no nsmb(8) manpage to be found anywhere, at least not on a freshly
rebuilt system. Maybe this manpage was left out while integrating
smbfs into the main kernel sources?

Cheers,
- --
Dimitry Andric <[EMAIL PROTECTED]>
PGP Key: http://www.xs4all.nl/~dim/dim.asc
Fingerprint: 7AB462D2CE35FC6D42394FCDB05EA30A2E2096A3

-BEGIN PGP SIGNATURE-
Version: PGP 6.5i
Comment: http://www.gn.apc.org/duncan/stoa_cover.htm

iQA/AwUBO2wjgrBeowouIJajEQLtXwCg16tS7WhijvzFke/TkP33JDArXeMAoIgz
FFhftYgBLJGr3IW4shs3H3Q0
=2Swi
-END PGP SIGNATURE-


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

Re: Access disallowed through ssh

[Dimitry Andric]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2001-09-03 at 23:03:20 Conrado Vardanega wrote:

CV> "Received disconnect from 200.193.xx.xx: 2: Sorry, you are not allowed to
CV> connect."
- --snip--
CV> This began sometime with no apparent changes to the system. The hosts.allow
CV> is default, which already allowed me access it in the past.

Check your (reverse) DNS lookups and/or server. If the address you are
connecting from doesn't resolve properly, you'll be denied, due to the
following lines in the default hosts.allow:

# Protect against simple DNS spoofing attacks by checking that the
# forward and reverse records for the remote host match. If a mismatch
# occurs, access is denied, and any positive ident response within
# 20 seconds is logged. No protection is afforded against DNS poisoning,
# IP spoofing or more complicated attacks. Hosts with no reverse DNS
# pass this rule.
ALL : PARANOID : RFC931 20 : deny

I've had my DNS server drop out on me more than once, and each time I
get exactly those problems you mention with tcpwrappers. :)

Cheers,
- --
Dimitry Andric <[EMAIL PROTECTED]>
PGP Key: http://www.xs4all.nl/~dim/dim.asc
Fingerprint: 7AB462D2CE35FC6D42394FCDB05EA30A2E2096A3

-BEGIN PGP SIGNATURE-
Version: PGP 6.5i
Comment: http://www.gn.apc.org/duncan/stoa_cover.htm

iQA/AwUBO5PyprBeowouIJajEQKDLACeI549TkbHY/arJHlSbLXO7DcDIE4An1We
DX2VBhQi3w4AVhVdnE02R3dD
=0FXG
-END PGP SIGNATURE-


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

Re[2]: fxp half-duplex problemm

[Dimitry Andric]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2001-12-13 at 19:22:30 David Greenman wrote:

DG>How about:

DG> ifconfig fxp0 media 100basetx mediaopt half-duplex

That will give you "ifconfig: SIOCSIFMEDIA: Device not configured",
because this mediaopt option is not (no longer?) supported for fxp(4).
By NOT specifying any mediaopt option, you specify half-duplex
implicitly. Or you can `subtract' the full-duplex option with
"-mediaopt full-duplex", as stated earlier.

At the moment there are some NICs (fxp, xl, etc) that have this way of
specifying half/full-duplex, and some others --not sure which-- don't,
so these have an explicit "half-duplex" mediaopt. The man pages don't
always agree with reality, however... :(

Cheers,
- --
Dimitry Andric <[EMAIL PROTECTED]>
PGP Key: http://www.xs4all.nl/~dim/dim.asc
Fingerprint: 7AB462D2CE35FC6D42394FCDB05EA30A2E2096A3
Lbh ner abj va ivbyngvba bs gur QZPN

-BEGIN PGP SIGNATURE-
Version: PGP 6.5i
Comment: http://www.gn.apc.org/duncan/stoa_cover.htm

iQA/AwUBPBlq37BeowouIJajEQId4QCfQtYVs4kxr9Xbd8DXX2p0fX2Lf1cAoOW2
JN5yz90YkVPoVtMnvEQ5ZrMs
=45Ke
-END PGP SIGNATURE-


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

Re: fxp half-duplex problemm

[Dimitry Andric]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2001-12-14 at 05:00:46 David Greenman wrote:

>>That will give you "ifconfig: SIOCSIFMEDIA: Device not configured",
>>because this mediaopt option is not (no longer?) supported for fxp(4).

DG>I would consider that a bug.

Well, in the case of fxp(4), the man page is quite clear:

 The fxp driver supports the following media options:

 full-duplex   Set full duplex operation

(end of list)

It doesn't really make sense to have separate options for half and
full duplex, because they are mutually exclusive anyway. So one of
them was dropped. I'm not sure, but it seems to be the case with all
NIC drivers using the common miibus code.

Cheers,
- --
Dimitry Andric <[EMAIL PROTECTED]>
PGP Key: http://www.xs4all.nl/~dim/dim.asc
Fingerprint: 7AB462D2CE35FC6D42394FCDB05EA30A2E2096A3
Lbh ner abj va ivbyngvba bs gur QZPN

-BEGIN PGP SIGNATURE-
Version: PGP 6.5i
Comment: http://www.gn.apc.org/duncan/stoa_cover.htm

iQA/AwUBPBlwd7BeowouIJajEQLq7QCdEHn20kFde6UgdVK5trNsuV9SeuYAnjEn
6qJ4wFrGy6vqd9sNegF0c98L
=5Ft5
-END PGP SIGNATURE-


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

Re: mount_smbfs error

[Dimitry Andric]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2001-12-25 at 06:28:49 David Xu wrote:

DX> smbfs: can't get handle to requester (no /dev/net/nsmb* device)

The problem is that the required /dev/nsmb0 device is not created
during make world. See this PR for more info:

  http://www.freebsd.org/cgi/query-pr.cgi?pr=33068

It seems the fix for this didn't get committed yet, so please
work around this for now by manually creating it. Just run:

  mknod /dev/nsmb0 c 144 0

as root, and you should be able to use mount_smbfs.

Cheers,
- --
Dimitry Andric <[EMAIL PROTECTED]>
PGP Key: http://www.xs4all.nl/~dim/dim.asc
Fingerprint: 7AB462D2CE35FC6D42394FCDB05EA30A2E2096A3
Lbh ner abj va ivbyngvba bs gur QZPN

-BEGIN PGP SIGNATURE-
Version: PGP 6.5i
Comment: http://www.gn.apc.org/duncan/stoa_cover.htm

iQA/AwUBPCgfSLBeowouIJajEQKUnQCZAcqBoGq9/W1C5KUnp74NMps5K9YAniA2
rL73dp6TswFOOo51rPZdBdsd
=svAD
-END PGP SIGNATURE-


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

Re: mount_smbfs error

[Dimitry Andric]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2001-12-25 at 09:49:50 David Xu wrote:

DX> Thanks,  problem disappeared.
DX> but why prints  "/dev/net/nsmb*"?

That is indeed confusing, and I already reported it in the PR too.
Please be patient: the fix for this is pending, as you can read in the
PR followups.

Cheers,
- --
Dimitry Andric <[EMAIL PROTECTED]>
PGP Key: http://www.xs4all.nl/~dim/dim.asc
Fingerprint: 7AB462D2CE35FC6D42394FCDB05EA30A2E2096A3
Lbh ner abj va ivbyngvba bs gur QZPN

-BEGIN PGP SIGNATURE-
Version: PGP 6.5i
Comment: http://www.gn.apc.org/duncan/stoa_cover.htm

iQA/AwUBPCgzerBeowouIJajEQK9jwCg3k6p4A2ikN5K0SwjOLSr75s6Jm0AoIaw
DgRI0V2+RQrOhDAN6vqmZ7pV
=zebT
-END PGP SIGNATURE-


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