Support of the Intel HD 4600 (Haswell) graphics seems to be broken

[Rostislav Krasny]

Hi,

I've FreeBSD 11.1-RELEASE-p1 installed on an Intel Core i7 4790 based
machine. I use the CPU integrated HD 4600 graphics and its support
seems to be broken.

Can't start Lumina and Xfce. Can start the standard xorg's twm
(startx) but Firefox can't use DRM or D-Bus and crashes. See
screenshots of errors saved at the following URLs:

http://i66.tinypic.com/287k5s2.jpg
http://i66.tinypic.com/33bmko4.jpg

Xorg logs have no error.

Is it a known issue? Any workaround?
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Installing amd64 FreeBSD 11.1 in dual-boot with Windows 7 on an MBR partitioned disk

[Rostislav Krasny]

On Sat, Oct 7, 2017 at 6:26 PM, Warner Losh  wrote:
> Sorry for top posting. Sounds like your BIOS will read the botox64.efi from
> the removable USB drive, but won't from the hard drive. Force BIOS booting
> instead of UEFI and it will install correctly. However, it may not boot
> Windows, which I think requires UEFI these days.
>
> The root of the problem is that we have no way to setup the EFI boot
> variables in the installer that we need to properly installed under UEFI.
> I'm working on that, so you'll need to be patient...
>
> Warner

My computer doesn't have any EFI partition and this explains why the
installed FreeBSD boots in the BIOS mode on it. The installation media
probably has the EFI partition (with the bootx64.efi) and then BIOS
probably boots the installation media in the UEFI mode instead of the
BIOS mode. So the "machdep.bootmethod" sysctl doesn't represent the
BIOS boot mode configuration but a boot method the currently running
system was booted in. If this is true then the "machdep.bootmethod"
sysctl should not be used in bsdinstall. At least not for the
bootability check. Something else should be used for the bootability
check or the bsdinstall should trust the user choice.

BTW this is how the EFI partition looks like in someone's Windows 7
disk manager:
https://www.easyuefi.com/wintousb/images/en_US/efi-system-partition.png
and this how it looks without any EFI partition in my system (with
Windows 7 / FreeBSD dual-boot)
http://i68.tinypic.com/9u19b8.png

I think even that NTFS System Reserved partition is not mandatory for
Windows installation. It just used to keep Windows boot files in a
safe, place preventing accidental deletion by a user. It's being
created if Windows is installed on an empty disk but if you create
just one big NTFS partition prior to the Windows installation and
install it on that single partition it will be ok. There will be just
more Windows system files on the C disk, for example ntldr,
NTDETECT.COM. It can be checked on VM, for example on VirtualBox.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Installing amd64 FreeBSD 11.1 in dual-boot with Windows 7 on an MBR partitioned disk

[Rostislav Krasny]

On Fri, Oct 6, 2017 at 8:33 PM, Eugene Grosbein <eu...@grosbein.net> wrote:
> 06.10.2017 22:17, Rostislav Krasny wrote:
>
>> I consider this as a critical bug. But maybe there is some workaround
>> that allows me to install the FreeBSD 11.1 as a second OS without
>> repartitioning the entire disk?
>>
>> My hardware is an Intel Core i7 4790 3.6GHz based machine with 16GB
>> RAM. The ada0 disk is 238GB SanDisk SD8SBAT256G1122 (SSD).
>
> bsdinstall (current installer) is seriously flawed comparing with sysinstall 
> (previous one)
> when we talk about installing FreeBSD to a slice within MBR.

I think the bug is somewhere in the following code taken from partedit_x86.c
https://svnweb.freebsd.org/base/release/11.1.0/usr.sbin/bsdinstall/partedit/partedit_x86.c?revision=321354=co
or in the code that fills the "machdep.bootmethod" sysctl

static const char *
x86_bootmethod(void)
{
static char fw[255] = "";
size_t len = sizeof(fw);
int error;

if (strlen(fw) == 0) {
error = sysctlbyname("machdep.bootmethod", fw, , NULL, -1);
if (error != 0)
return ("BIOS");
}

return (fw);
}

int
is_scheme_bootable(const char *part_type)
{

if (strcmp(part_type, "GPT") == 0)
return (1);
if (strcmp(x86_bootmethod(), "BIOS") == 0) {
if (strcmp(part_type, "BSD") == 0)
return (1);
if (strcmp(part_type, "MBR") == 0)
return (1);
}

return (0);
}

I've checked and found following:
If booted from the installation media (USB drive) the
"machdep.bootmethod" is UEFI.
If booted from the already installed and updated 11.1-RELEASE-p1
system the "machdep.bootmethod" is BIOS.

This explains why I got that "is not bootable on this platform" error
message and similar warning (in case of manual partitioning). In my
case the part_type is "MBR" and the x86_bootmethod() returns "UEFI",
so is_scheme_bootable() returns 0 and triggers the bug.

I also made a screenshot of my BIOS boot mode configuration:
http://i63.tinypic.com/k3g2v.jpg
As you can see the legacy boot mode is enabled and the secure boot
mode is disabled.

If the machdep.bootmethod made to represent the BIOS configuration
then it's value seems to be wrong.
If it represents something else it should not be used in the above and
probably in other bsdinstall code.

> You still can install FreeBSD by invoking a shell from bsdinstall
> and using gpart:
>
> gpart add -t freebsd -a 4096 ada0# dedicate all unallocated space for 
> ada0s3
> gpart create -s BSD -n 20 ada0s3 # create BSD label able to contain upto 
> 20 partitions
> gpart bootcode -b /boot/boot0 ada0   # install menu-driven boot manager 
> BootEasy to MBR
> gpart bootcode -b /boot/boot ada0s3  # install FreeBSD-specific UFS boot code 
> to its slice
> gpart set -a active -i 1 ada0# make sure MBR has exactly one active 
> partition
> gpart add -t freebsd-swap -s 4G -i 2 # allocate 4G for a swap ada0s3b (choose 
> size of your like)
> gpart add -t freebsd-ufs -s 2G   # allocate 2G for root partition ada0s3a
> newfs -L root /dev/ada0s3a
> gpart add -t freebsd-ufs -s 1G   # allocate 1G for read-only /usr 
> partition ada0s3d
> newfs -L usr /dev/ada0s3d
> gpart add -t freebsd-ufs -s 4G   # allocate 4G for /var ada0s3e
> newfs -L var /dev/ada0s3e
> gpart add -t freebsd-ufs -s 10G  # allocate 10G /usr/local: future 
> installed ports & packages
> newfs -L usrl /dev/ada0s3f
> gpart add -t freebsd-ufs # allocate all other space for /home
> newfs -L home /dev/ada0s3g
>
> Then you will have mount new ada0s3a, create mount points for other 
> partitions there,
> create etc/fstab, extract *.txz from distibution media and it will boot just 
> fine.

This commands list is too long to be run manually during the
installation and without any web/email access. I've just installed
FreeBSD again using the manual partitioning (ignored the warning
message) and then I ran two following commands:

boo0cfg -Bv /dev/ada0
gpart bootcode -b /boot/boot ada0s3

This made my FreeBSD 11.1 system bootable. The only issue now is a low
console resolution. When I boot from the installation media (the USB
drive) the console resolution is high/native already at the boot
loader/menu stage. When I boot the installed system the console
resolution is low. I compared /boot/loader.conf of both and didn't
find much difference. In the installation media it has just one line
that defines some timeout and in the installed system it's empty. How
can I fix the console resolution issue? How the installation media
does it?
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Installing amd64 FreeBSD 11.1 in dual-boot with Windows 7 on an MBR partitioned disk

[Rostislav Krasny]

Hi there,

I try to install amd64 FreeBSD 11.1 in dual-boot with Windows 7 on an
MBR partitioned disk and I can't make it bootable. My Windows 7 uses
its standard MBR partitioning scheme (1. 100MB System Reserved
Partition; 2 - 127GB disk C partition) and there is about 112GB of
free unallocated disk space that I want to use to install FreeBSD on
it. As an installation media I use the
FreeBSD-11.1-RELEASE-amd64-mini-memstick.img flashed on a USB drive.

During the installation, if I choose to use Guided Partitioning Tool
and automatic partitioning of the free space, I get a pop-up message
that says:

==
The existing partition scheme on this disk
(MBR) is not bootable on this platform. To
install FreeBSD, it must be repartitioned.
This will destroy all data on the disk.
Are you sure you want to proceed?
 [Yes]  [No]
==

If instead of the Guided Partitioning Tool I choose to partition the
disk manually I get a similar message as a warning and the
installation process continues without an error, but the installed
FreeBSD system is not bootable. Installing boot0 manually (boot0cfg
-Bv /dev/ada0) doesn't fix it. The boot0 boot loader is able to boot
Windows but it's unable to start the FreeBSD boot process. It only
prints hash symbols when I press F3 (the FreeBSD slice/MBR partition
number).

I consider this as a critical bug. But maybe there is some workaround
that allows me to install the FreeBSD 11.1 as a second OS without
repartitioning the entire disk?

My hardware is an Intel Core i7 4790 3.6GHz based machine with 16GB
RAM. The ada0 disk is 238GB SanDisk SD8SBAT256G1122 (SSD).
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: I'm upset about FreeBSD

[Rostislav Krasny]

On Tue, Oct 18, 2016 at 21:57:29 +1100, Ian Smith  wrote:
>
> If FreeBSD GPT images (and Kindle readers) can trigger this, so could a
> theoretically unlimited combination of data on block 2 of USB media;
> modifying FreeBSD to fix a Windows bug should be out of the question.

Not modifying FreeBSD and not fixing Windows bug but modifying the
FreeBSD installation media and working around the Windows bug to let
people install FreeBSD without disappointing at very beginning. Why
GPT is used in the memstick images at all? Why they can't be MBR
based? I think they can.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: I'm upset about FreeBSD

[Rostislav Krasny]

On Mon, Oct 17, 2016 at 3:39 PM, Rostislav Krasny <rosti@gmail.com> wrote:
> On Mon, Oct 17, 2016 at 3:31 PM, krad <kra...@gmail.com> wrote:
>>
>> Does this just affect MBR layouts? If possible you might want to consider
>> UEFI booting for both windows and other os's, It's probably safer as you
>> dont need to plays with partitions and bootloaders.
>
> This is an old computer that doesn't support UEFI booting. In a past I
> tried older FreeBSD versions on it and I don't remember any boot issue
> with them. At least up to 9.X versions.

Ok. I dropped the FreeBSD ada0s2 slice and rewrote the MBR code by
MbrFix util from www.sysint.no/mbrfix
Then I tried to install FreeBSD 11.0 again. Previously I used the
manual partitioning and now I used the guided UFS partitioning. This
time FreeBSD was installed properly without any boot issue. FreeBSD
was booting straight away. After that I ran "boot0cfg -B ada0" and the
boot0 boot manager is working properly again: both F1 for Windows and
F2 for FreeBSD.

It's much better than in my first try. There probably is some bug in
the bsdinstall(8) when the manual partitioning is used instead of the
guided one.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: I'm upset about FreeBSD

[Rostislav Krasny]

On Mon, Oct 17, 2016 at 3:31 PM, krad  wrote:
>
> Does this just affect MBR layouts? If possible you might want to consider
> UEFI booting for both windows and other os's, It's probably safer as you
> dont need to plays with partitions and bootloaders.

This is an old computer that doesn't support UEFI booting. In a past I
tried older FreeBSD versions on it and I don't remember any boot issue
with them. At least up to 9.X versions.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: I'm upset about FreeBSD

[Rostislav Krasny]

On 17.10.2016 11:57:16 +0500, Eugene M. Zheganin wrote:
> Hi.
>
> On 17.10.2016 5:44, Rostislav Krasny wrote:
> > Hi,
> >
> > I've been using FreeBSD for many years. Not as my main operating
> > > system, though. But anyway several bugs and patches were contributed
> > and somebody even added my name into the additional contributors list.
> > That's pleasing but today I tried to install the FreeBSD 11.0 and I'm
> > > upset about this operating system.
> >
> > First of all I faced an old problem that I reported here a year ago:
> > http://comments.gmane.org/gmane.os.freebsd.stable/96598
> > > Completely new USB flash drive flashed by the
> > FreeBSD-11.0-RELEASE-i386-mini-memstick.img file kills every Windows
> > again. If I use the Rufus util to write the img file (using DD mode)
> > the Windows dies immediately after the flashing. If I use the
> > Win32DiskImager (suggested by the Handbook) it doesn't reinitialize
> > the USB storage and Windows dies only if I remove and put that USB
> > flash drive again or boot Windows when it is connected. Nothing was
> > done to fix this nasty bug for a year.
>
> I saw this particular bug, and I must say - man, it's not FreeBSD, it's Rufus.
> So far Windows doesn't have any decent tool to write the image with. As
> about Rufus - somehow it does produce broken images on a USB stick
> (not always though), which make every Windows installation to BSOD
> immediately after inserting. And this continues until you reinitialize the
> stick boot area.

The DD mode in Rufus and in any other flashing util that supports the
DD mode (including the native dd(1) program) just writes the image
file byte by byte without any change, isn't it? If you say the boot
area re-initialization resolves the BSOD issue then why the boot area
isn't fixed in the image file at the first place? I agree that Windows
has a serious bug but why FreeBSD doesn't try to workaround it? After
all people try to install FreeBSD and if the Windows bug and the
FreeBSD developers stubbornness prevent them to do so they just can't
and won't install FreeBSD. This is a lose-lose situation.

> P.S. By the way, win32diskimager is a total mess too. Sometimes it just
> does nothing instead of writing an image. I did try almost all of the free
>  win32 tools to write image with, and didn't find any that would completely
> satisfy me. Rufus would be the best, if it didn't have this ridiculous bug 
> with
> BSOD.

Did you try the native FreeBSD dd(1) program or a MinGW version of dd(1)?

And what about other issues I've described in my first email? I
managed to install FreeBSD 11.0 but it still unbootable.


P.S. please Cc your replies to me since I don't receive this mailing
list emails directly, although I'm subscribed.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

I'm upset about FreeBSD

[Rostislav Krasny]

Hi,

I've been using FreeBSD for many years. Not as my main operating
system, though. But anyway several bugs and patches were contributed
and somebody even added my name into the additional contributors list.
That's pleasing but today I tried to install the FreeBSD 11.0 and I'm
upset about this operating system.

First of all I faced an old problem that I reported here a year ago:
http://comments.gmane.org/gmane.os.freebsd.stable/96598
Completely new USB flash drive flashed by the
FreeBSD-11.0-RELEASE-i386-mini-memstick.img file kills every Windows
again. If I use the Rufus util to write the img file (using DD mode)
the Windows dies immediately after the flashing. If I use the
Win32DiskImager (suggested by the Handbook) it doesn't reinitialize
the USB storage and Windows dies only if I remove and put that USB
flash drive again or boot Windows when it is connected. Nothing was
done to fix this nasty bug for a year.

Ok, I've used the trick and rebooted Windows manually into the BIOS
setup right after I flashed the USB disk by the Win32DiskImager. The
FreeBSD 11.0 installation has started. I did it on my old computer
with MBR disk schema and installed the FreeBSD on the second MBR slice
(ada0s2). The installation finished. I changed the BIOS boot
configuration back, started to reboot and quickly removed the USB
flash drive (I didn't want to kill Windows again). But suddenly my
computer appeared unbootable. The new MBR code, that was rewritten
without any notation, can't find any OS. I tried to reboot several
times. Why bsdinstall doesn't ask about changing the MBR code? Maybe I
don't want to change it. Or maybe I want to install the BSD boot
manager version of the MBR code (boot0cfg -B).

Ok, I booted from the installation USB drive again and ran 'boot0cfg
-B ada0'. My computer is bootable again, but only for Windows. If I
press F1 the Windows boots properly. If I press F2 or F2 and Enter I
see only hash tags. If I reboot after that I see F2 already selected.
But if I wait (for F2 - FreeBSD) to the selected OS automatic boot I
see the hash tags again. WTF? I've never seen such bugs with boot0 in
any previous FreeBSD version.

I'm upset. Someone else at my place was throwing the FreeBSD 11.0
installation media far away right after the first problem. What is
going on? At least, how to finish the quest?

FreeBSD is losing popularity for Linux these days. I think such a bad
user experience of very basic use cases is one of the main reason for
this loss. Forgive me for saying that, I'm just upset.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD-10.2-RELEASE-i386-memstick.img kills every Windows it touch

[Rostislav Krasny]

There is no GPT parser in Windows XP because XP doesn't support it. Windows
7 supports it and dies differently. But why to use GPT in the installation
stick in the first place? You don't use any advantage of GPT and on old
hardware even can't use GPT during boot but its MBR compatibility. That's
obvious that XP and 7 have some epic bugs with GPT, but why to trigger them
if you can use MBR? After all you need only one partition for the FreeBSD
installation files. MBR does this job perfectly.

BTW why FreeBSD installation files resides in the second partition of GPT
(/dev/da0p2)? Maybe this is the trigger of the Windows bug? As far as I
know at least XP doesn't support more than one MBR partition on an USB
stick.

On Sat, Nov 14, 2015 at 12:19 PM, Florian Ermisch <0xf...@fsfe.org> wrote:

> The GPT message is nothing to worry about, that's normal with an image
> smaller than the underlying disk.
> The image might trigger a bug in M$'s GPT parser though. 2004ish there was
> a small bug in the installer of Mandrake Linux rendering a otherwise fine
> disk unusable for Windows XP so I wouldn't be too surprised.
>
> Regards, Florian
>
> Am 14. November 2015 01:09:16 MEZ, schrieb Rostislav Krasny <
> rosti@gmail.com>:
> > I've installed FreeBSD 10.2 from CD and successfully mounted this
> > stick
> > (/dev/da0p2).
> > At least in FreeBSD it doesn't make any problem. Before I mounted it
> > there
> > was some messages on the consle. You can see the screenshot there:
> > http://oi67.tinypic.com/351yiqd.jpg
> > On the last line of that message it says that: "the secondary GPT
> > header is
> > not in the last LBA".
> >
> > Then I repartitioned (with MBR schema) and reformatted it and voila it
> > works properly on Windows as before FreeBSD. So there is no hardware
> > problem with this stick, for sure.
> >
> >
> > On Sat, Nov 14, 2015 at 1:16 AM, Florian Ermisch <0xf...@fsfe.org>
> > wrote:
> >
> > > Hi Rostislav,
> > >
> > > did you verify it's the image and not the stick?
> > > I've seen a USB-headset and a Dell USB-kbd with integrated
> > > smartcard-reader pulling of such a stunt. Both were used on windows
> > > machines before and then suddenly started crashing them.
> > >
> > > Regards, Florian
> > >
> > > Am 13. November 2015 23:10:59 MEZ, schrieb Rostislav Krasny <
> > > rosti@gmail.com>:
> > > > Hi there,
> > > >
> > > > You might not belive me but it really does. I just flashed the
> > > > FreeBSD-10.2-RELEASE-i386-memstick.img installation image on a 2GB
> > > > disk on
> > > > key using Rufus 2.5. Rufus is a Windows program that support
> > flashing
> > > > img
> > > > files into USB disk on key in DD mode (like the dd(1) program).
> > Now
> > > > every
> > > > time I connect this disk on key into my old computer with Windows
> > XP
> > > > it
> > > > reboots instantly. First time it rebooted right after Rufus
> > finished
> > > > the
> > > > flashing. If I connect it into my Dell Latitude E7440 laptop with
> > > > Windows 7
> > > > there is a BSOD. There was no such reboot with this disk on key
> > before
> > > > I
> > > > flashed it with the FreeBSD-10.2-RELEASE-i386-memstick.img
> > > >
> > > > What is going on here? What did you put into this image file?
> > > >
> > > > P.S. I've checked the MD5 hash of the image file and it's the same
> > to
> > > > the
> > > > official MD5 hash in www.freebsd.org/releases/10.2R/announce.html
> > As
> > > > far as
> > > > I remember I downloaded the image file from the official German
> > > > FreeBSD
> > > > mirror.
> > > > ___
> > > > freebsd-stable@freebsd.org mailing list
> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > > > To unsubscribe, send any mail to
> > > > "freebsd-stable-unsubscr...@freebsd.org"
> > >
> > >
>
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

FreeBSD-10.2-RELEASE-i386-memstick.img kills every Windows it touch

[Rostislav Krasny]

Hi there,

You might not belive me but it really does. I just flashed the
FreeBSD-10.2-RELEASE-i386-memstick.img installation image on a 2GB disk on
key using Rufus 2.5. Rufus is a Windows program that support flashing img
files into USB disk on key in DD mode (like the dd(1) program). Now every
time I connect this disk on key into my old computer with Windows XP it
reboots instantly. First time it rebooted right after Rufus finished the
flashing. If I connect it into my Dell Latitude E7440 laptop with Windows 7
there is a BSOD. There was no such reboot with this disk on key before I
flashed it with the FreeBSD-10.2-RELEASE-i386-memstick.img

What is going on here? What did you put into this image file?

P.S. I've checked the MD5 hash of the image file and it's the same to the
official MD5 hash in www.freebsd.org/releases/10.2R/announce.html As far as
I remember I downloaded the image file from the official German FreeBSD
mirror.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD-10.2-RELEASE-i386-memstick.img kills every Windows it touch

[Rostislav Krasny]

I've installed FreeBSD 10.2 from CD and successfully mounted this stick
(/dev/da0p2).
At least in FreeBSD it doesn't make any problem. Before I mounted it there
was some messages on the consle. You can see the screenshot there:
http://oi67.tinypic.com/351yiqd.jpg
On the last line of that message it says that: "the secondary GPT header is
not in the last LBA".

Then I repartitioned (with MBR schema) and reformatted it and voila it
works properly on Windows as before FreeBSD. So there is no hardware
problem with this stick, for sure.


On Sat, Nov 14, 2015 at 1:16 AM, Florian Ermisch <0xf...@fsfe.org> wrote:

> Hi Rostislav,
>
> did you verify it's the image and not the stick?
> I've seen a USB-headset and a Dell USB-kbd with integrated
> smartcard-reader pulling of such a stunt. Both were used on windows
> machines before and then suddenly started crashing them.
>
> Regards, Florian
>
> Am 13. November 2015 23:10:59 MEZ, schrieb Rostislav Krasny <
> rosti@gmail.com>:
> > Hi there,
> >
> > You might not belive me but it really does. I just flashed the
> > FreeBSD-10.2-RELEASE-i386-memstick.img installation image on a 2GB
> > disk on
> > key using Rufus 2.5. Rufus is a Windows program that support flashing
> > img
> > files into USB disk on key in DD mode (like the dd(1) program). Now
> > every
> > time I connect this disk on key into my old computer with Windows XP
> > it
> > reboots instantly. First time it rebooted right after Rufus finished
> > the
> > flashing. If I connect it into my Dell Latitude E7440 laptop with
> > Windows 7
> > there is a BSOD. There was no such reboot with this disk on key before
> > I
> > flashed it with the FreeBSD-10.2-RELEASE-i386-memstick.img
> >
> > What is going on here? What did you put into this image file?
> >
> > P.S. I've checked the MD5 hash of the image file and it's the same to
> > the
> > official MD5 hash in www.freebsd.org/releases/10.2R/announce.html As
> > far as
> > I remember I downloaded the image file from the official German
> > FreeBSD
> > mirror.
> > ___
> > freebsd-stable@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to
> > "freebsd-stable-unsubscr...@freebsd.org"
>
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: possible tcp problem

[Rostislav Krasny]

Hi,

On Fri, 19 May 2006 15:49:25 +0200
Andras Got [EMAIL PROTECTED] wrote:

 The question is that what could cause this thing and what should we try to 
 solve this.
 
 Errors:
 sendmail[37085]: gethostbyaddr(IP) failed: 1
 Can't connect to MySQL server on 'IP' (1)

Don't know about the second error, but I believe the first one is
printed by following chunk of src/contrib/sendmail/src/conf.c

 start of the quote 
sm_syslog(LOG_WARNING, NOQID,
  gethostbyaddr(%.100s) failed: %d,
  anynet_ntoa(sa),
#if NAMED_BIND
  h_errno
#else /* NAMED_BIND */
  -1
#endif /* NAMED_BIND */
 );
 end of the quote 

netdb.h has following description for that error number in h_errno:

#define HOST_NOT_FOUND  1 /* Authoritative Answer Host not found */

So that specific error looks like a problem on your DNS.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: system crash during file copy to a floppy with bad sectors

[Rostislav Krasny]

On Sat, 6 May 2006 09:36:31 +0930
Daniel O'Connor [EMAIL PROTECTED] wrote:

 On Saturday 06 May 2006 09:33, Rostislav Krasny wrote:
   Can you get a back trace? ie enable crash dumps and do it again, or
   transcribe, or photograph the screen as it panics if you are local.
 
  Unfortunately I cannot reproduce it now. Doesn't the old log help?
  There is one Fatal trap 12.
 
 Only if you have the backtrace I think.

In attempt to emulate bad sectors I got another crash, that looks
similar (but not exactly same) to the original two crashes. I just
pulled out the diskette before file copy is finished. I know, that
must never be done, but sometimes people are in a great hurry or just
do mistakes. IMHO that isn't a good reason for a system crash.

The trace of that crash is attached to this email. This time g_vfs_done()
returned other error.

In other attemt to emulate bad sectors the kernel entered to an
endless loop of printing g_vfs_done() errors. I was able to switch
terminals (by Alt+F1, Alt+F2, ...) but unable to type anything or reboot
the system by Ctrl+Alt+Del.


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

Re: system crash during file copy to a floppy with bad sectors

[Rostislav Krasny]

On Fri, 5 May 2006 10:01:09 +0930
Daniel O'Connor [EMAIL PROTECTED] wrote:

 On Friday 05 May 2006 07:41, Rostislav Krasny wrote:
  write the same file to the same floppy I didn't run umount and it crashed
  again. Following are footsteps of the first crash, founded in the
  /var/log/messages. I hope they may help to localize the problem. From the
  log it looks like some VFS problem.
 
 Can you get a back trace? ie enable crash dumps and do it again, or 
 transcribe, or photograph the screen as it panics if you are local.

Unfortunately I cannot reproduce it now. Doesn't the old log help?
There is one Fatal trap 12.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

system crash during file copy to a floppy with bad sectors

[Rostislav Krasny]

Hi everybody,

 uname -a
FreeBSD saturn.lan 6.1-RC FreeBSD 6.1-RC #0: Mon May  1 16:18:59 IDT 2006 
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYKERNEL  i386

This system crashed during copying of one file (about 1Mb) to a floppy which
has bad sectors. The floppy was mounted by mount_msdosfs and I ran cp as root.
Before the crash I also ran umount. But in my second attempt to write the same
file to the same floppy I didn't run umount and it crashed again. Following
are footsteps of the first crash, founded in the /var/log/messages. I hope they
may help to localize the problem. From the log it looks like some VFS problem.

May  2 23:13:09 saturn kernel: g_vfs_done():fd0[WRITE(offset=35328, 
length=4096)]error = 5
May  2 23:13:09 saturn kernel: g_vfs_done():fd0[WRITE(offset=51712, 
length=4096)]error = 5
May  2 23:13:10 saturn kernel: g_vfs_done():fd0[WRITE(offset=72192, 
length=4096)]error = 5
May  2 23:13:10 saturn kernel: g_vfs_done():fd0[WRITE(offset=88576, 
length=4096)]error = 5
May  2 23:13:11 saturn kernel: g_vfs_done():fd0[WRITE(offset=109056, 
length=4096)]error = 5
May  2 23:13:11 saturn kernel: g_vfs_done():fd0[WRITE(offset=125440, 
length=4096)]error = 5
May  2 23:13:12 saturn kernel: g_vfs_done():fd0[WRITE(offset=145920, 
length=4096)]error = 5
May  2 23:13:12 saturn kernel: g_vfs_done():fd0[WRITE(offset=162304, 
length=4096)]error = 5
May  2 23:13:13 saturn kernel: g_vfs_done():fd0[WRITE(offset=182784, 
length=4096)]error = 5
May  2 23:13:13 saturn kernel: g_vfs_done():fd0[WRITE(offset=199168, 
length=4096)]error = 5
May  2 23:13:14 saturn kernel: g_vfs_done():fd0[WRITE(offset=35328, 
length=4096)]error = 5
May  2 23:13:14 saturn kernel: g_vfs_done():fd0[WRITE(offset=51712, 
length=4096)]error = 5
May  2 23:13:15 saturn kernel: g_vfs_done():fd0[WRITE(offset=72192, 
length=4096)]error = 5
May  2 23:13:15 saturn kernel: g_vfs_done():fd0[WRITE(offset=88576, 
length=4096)]error = 5
May  2 23:13:15 saturn kernel: g_vfs_done():fd0[WRITE(offset=109056, 
length=4096)]error = 5
May  2 23:13:15 saturn kernel: g_vfs_done():fd0[WRITE(offset=125440, 
length=4096)]error = 5
May  2 23:13:15 saturn kernel: g_vfs_done():fd0[WRITE(offset=145920, 
length=4096)]error = 5
May  2 23:13:16 saturn kernel: g_vfs_done():fd0[WRITE(offset=162304, 
length=4096)]error = 5
May  2 23:13:16 saturn kernel: g_vfs_done():fd0[WRITE(offset=182784, 
length=4096)]error = 5
May  2 23:13:16 saturn kernel: g_vfs_done():fd0[WRITE(offset=199168, 
length=4096)]error = 5
May  2 23:13:16 saturn kernel: g_vfs_done():fd0[WRITE(offset=219648, 
length=4096)]error = 5
May  2 23:13:17 saturn kernel: g_vfs_done():fd0[WRITE(offset=236032, 
length=4096)]error = 5
May  2 23:13:17 saturn kernel: g_vfs_done():fd0[WRITE(offset=256512, 
length=4096)]error = 5
May  2 23:13:18 saturn kernel: g_vfs_done():fd0[WRITE(offset=272896, 
length=4096)]error = 5
May  2 23:13:18 saturn kernel: g_vfs_done():fd0[WRITE(offset=293376, 
length=4096)]error = 5
May  2 23:13:19 saturn kernel: g_vfs_done():fd0[WRITE(offset=309760, 
length=4096)]error = 5
May  2 23:13:19 saturn kernel: g_vfs_done():fd0[WRITE(offset=330240, 
length=4096)]error = 5
May  2 23:13:20 saturn kernel: g_vfs_done():fd0[WRITE(offset=346624, 
length=4096)]error = 5
May  2 23:13:20 saturn kernel: g_vfs_done():fd0[WRITE(offset=367104, 
length=4096)]error = 5
May  2 23:13:21 saturn kernel: g_vfs_done():fd0[WRITE(offset=383488, 
length=4096)]error = 5
May  2 23:13:21 saturn kernel: g_vfs_done():fd0[WRITE(offset=403968, 
length=4096)]error = 5
May  2 23:13:22 saturn kernel: g_vfs_done():fd0[WRITE(offset=420352, 
length=4096)]error = 5
May  2 23:13:22 saturn kernel: g_vfs_done():fd0[WRITE(offset=440832, 
length=4096)]error = 5
May  2 23:13:23 saturn kernel: g_vfs_done():fd0[WRITE(offset=457216, 
length=4096)]error = 5
May  2 23:13:23 saturn kernel: g_vfs_done():fd0[WRITE(offset=477696, 
length=4096)]error = 5
May  2 23:13:24 saturn kernel: g_vfs_done():fd0[WRITE(offset=494080, 
length=4096)]error = 5
May  2 23:13:24 saturn kernel: g_vfs_done():fd0[WRITE(offset=514560, 
length=4096)]error = 5
May  2 23:13:25 saturn kernel: g_vfs_done():fd0[WRITE(offset=530944, 
length=4096)]error = 5
May  2 23:13:25 saturn kernel: g_vfs_done():fd0[WRITE(offset=551424, 
length=4096)]error = 5
May  2 23:13:26 saturn kernel: g_vfs_done():fd0[WRITE(offset=567808, 
length=4096)]error = 5
May  2 23:13:26 saturn kernel: g_vfs_done():fd0[WRITE(offset=588288, 
length=4096)]error = 5
May  2 23:13:27 saturn kernel: g_vfs_done():fd0[WRITE(offset=604672, 
length=4096)]error = 5
May  2 23:13:27 saturn kernel: g_vfs_done():fd0[WRITE(offset=625152, 
length=4096)]error = 5
May  2 23:13:28 saturn kernel: g_vfs_done():fd0[WRITE(offset=641536, 
length=4096)]error = 5
May  2 23:13:28 saturn kernel: g_vfs_done():fd0[WRITE(offset=662016, 
length=4096)]error = 5
May  2 23:13:29 saturn kernel: g_vfs_done():fd0[WRITE(offset=678400, 
length=4096)]error = 5
May  2 23:13:29 saturn kernel: g_vfs_done():fd0[WRITE(offset=698880, 
length=4096)]error = 5
May  

Re: resolver doesn't see resolv.conf changes

[Rostislav Krasny]

 when switching my laptop from LAN to a dialup connection, applications
 started _before_ the switch will still try to send DNS queries to my
 local DNS server. This isn't ideal, and the only workaround I've found
 so far is to restart the application.
 
 Is the resolver supposed to periodically check for updates to the
 resolv.conf, or are the applications somehow caching the IP of the DNS
 server?

If you're the author of the application you can periodically unset a
RES_INIT bit mask option in _res.options. Next time your application
will try to call res_send() it will call res_init() at first. This is
according to a resolver(3) manual page.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SSH login takes very long time...sometimes

[Rostislav Krasny]

On Wed, 1 Mar 2006 15:45:13 +0300
Yar Tikhiy [EMAIL PROTECTED] wrote:

 On Sat, Feb 25, 2006 at 04:28:50PM +0900, Hajimu UMEMOTO wrote:
   On Sat, 25 Feb 2006 02:42:46 +0200
   Rostislav Krasny [EMAIL PROTECTED] said:
  
  rosti I've found the problem in both: ftpd(8) and ftp(1). In the ftpd(8) a
  rosti getaddrinfo() is called in two places with hints.ai_socktype == 0 and
  rosti hints.ai_family == PF_UNSPEC. In the ftp(1) a command reply timeout 
  is
  rosti only 60 seconds. Those things are what I've changed to fix the 
  problem.
  rosti Two diffs are attached to this email. The ftpd.c.diff extends -4 and 
  -6
  rosti ftpd options. So if this patch is good, the ftpd(8) manual page and 
  the
  rosti default /etc/inetd.conf should also be changed appropriately.
  
  For your ftpd.c.diff, I like your idea to reduce redundant query.  It
  is enough to query just appropriate address family.  In inetd mode, we
  know the address family already.  So, we don't need to rely on the
  -4/-6 option.  The following diff is against ftpd.c with your patch
  applied:
 
 I finally tried the proposed patches for ftpd and really liked the
 idea of reducing the name queries made to only one address family
 if it's known.  Thank you both!
 
 I've got only one small remark on style, see below.
 
  --- ftpd.c.rostiSat Feb 25 15:41:52 2006
  +++ ftpd.c  Sat Feb 25 16:01:46 2006
  @@ -423,10 +423,6 @@ main(int argc, char *argv[], char **envp
  }
  }
   
  -#ifdef VIRTUAL_HOSTING
  -   inithosts(family);
  -#endif
  -
  if (daemon_mode) {
  int *ctl_sock, fd, maxfd = -1, nfds, i;
  fd_set defreadfds, readfds;
  @@ -456,6 +452,10 @@ main(int argc, char *argv[], char **envp
  sa.sa_handler = reapchild;
  (void)sigaction(SIGCHLD, sa, NULL);
   
  +#ifdef VIRTUAL_HOSTING
  +   inithosts(family);
  +#endif
  +
  /*
   * Open a socket, bind it to the FTP port, and start
   * listening.
  @@ -525,6 +525,14 @@ main(int argc, char *argv[], char **envp
  syslog(LOG_ERR, getpeername (%s): %m,argv[0]);
  exit(1);
  }
  +
  +#ifdef VIRTUAL_HOSTING
  +   family = his_addr.su_family;
  +   if (his_addr.su_family == AF_INET6 
  +   IN6_IS_ADDR_V4MAPPED(his_addr.su_sin6.sin6_addr))
  +   family = AF_INET;
 
 Perheps a better style here would be to use if/else:
 
   if (his_addr.su_family == AF_INET6 
   IN6_IS_ADDR_V4MAPPED(his_addr.su_sin6.sin6_addr))
   family = AF_INET;
   else
   family = his_addr.su_family;
 
  +   inithosts(family);

Or even shorter:

if (his_addr.su_family == AF_INET6 
IN6_IS_ADDR_V4MAPPED(his_addr.su_sin6.sin6_addr))
inithosts(AF_INET);
else
inithosts(his_addr.su_family);

The 'family' variable isn't used in the inetd mode.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SSH login takes very long time...sometimes

[Rostislav Krasny]

On Wed, 01 Mar 2006 00:28:14 +0900
Hajimu UMEMOTO [EMAIL PROTECTED] wrote:

 Hi,
 
  On Mon, 27 Feb 2006 18:19:54 +0300
  Yar Tikhiy [EMAIL PROTECTED] said:
 
 yar I finally spared some time to test your recent changes and found
 yar that the resolver still would retry using the first, and only the
 yar first, domain on the `search' list when the nameserver was down,
 yar which effectively led to another kind of request doubling.
 
 yar A similar effect was observed when a `domain' line was specified
 yar in resolv.conf in place of `search'.
 
 yar Is there a real reason to retry with a different domain when the
 yar nameserver doesn't respond at all?
 
 It seems yet another issue.  The errors returned by res_querydomain()
 are not handled uniformity.  Please try following patch:

Thank you! After applaying that additional patch a number of DNS
queries to unreachable name servers has decreased. Now, with three
unreachable name servers in resolv.conf and previously patched (my and
your patches) ftpd(8), I can successfully login to this machine by even
not patched ftp(1) from other FreeBSD 6.1-pre
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SSH login takes very long time...sometimes

[Rostislav Krasny]

Chuck Swiger [EMAIL PROTECTED] wrote:
 Yar Tikhiy wrote:
 [ ... ]
  A similar effect was observed when a `domain' line was specified
  in resolv.conf in place of `search'.
 
  Is there a real reason to retry with a different domain when the
  nameserver doesn't respond at all?

 UDP is lossy, and it may take a nameserver longer to respond that the client
 resolver library is willing to wait; the fact that a nameserver didn't answer
 once isn't a sure sign that it won't answer other questions, or even that it
 won't answer the same question if you just wait a minute.

Trying different domains isn't intended for fighting against UDP
packets loss. To fight against UDP packets loss you have RES_DFLRETRY
or options attempts:N retries of the same query. RES_DFLRETRY is
defined in resolv.h and options attempts:N is optional parameter of
/etc/resolv.conf.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SSH login takes very long time...sometimes

[Rostislav Krasny]

On Sun, 26 Feb 2006 09:45:34 +0900
Hajimu UMEMOTO [EMAIL PROTECTED] wrote:

 Hi,
 
  On Sun, 26 Feb 2006 01:46:30 +0200
  Rostislav Krasny [EMAIL PROTECTED] said:
 
 rosti.bsd As far as I understand the code of selecthost() it walks through 
 linked
 rosti.bsd lists of known virtual hosts and their addresses and compares the
 rosti.bsd addresses to a local address of connected socket. This way it 
 tries to
 rosti.bsd find - configuration of what virtual host should be used. There is 
 an
 rosti.bsd additional comparison that seems like a workaround for 
 misconfigured
 rosti.bsd virtual host that can be resolved only to IPv4 address and should 
 be
 rosti.bsd used on IPv4-mapped IPv6 address. If virtual hosts are properly
 rosti.bsd configured that hack is not needed, IMHO.
 
 If you nuke this workaround from both selecthost() and my patch, you
 need to specify a native IPv4 address and/or an IPv4-mapped IPv6
 address into ftphosts appropriately.  It will confuse users.  So, it
 is requierd.

It will require to specify a virtual host for each address or to use
hostname with multiple addresses only once. Specifying a virtual host by
a hostname and registering multiple hostname's addresses in /etc/hosts
should not be confusing, IMHO. If the addresses are already registered
on DNS, the work is even simpler.

Even specifying virtual hosts by addresses should not be confusing,
because IPv4-mapped IPv6 address and the IPv4-mapped itself are
certainly not the same, although they are mapped each to other. Indeed,
someone could want to specify different virtual ftp hosts for IPv4 and
mapped to it IPv6 addresses. For example to use different motd, welcome
or statfile files.

 rosti.bsd Anyway selecthost() is called with local socket name and it checks 
 a
 rosti.bsd local address, while his_addr.su_sin6.sin6_addr is a remote 
 address.
 rosti.bsd Local and remote hosts have same address families but not same
 rosti.bsd addresses.
 
 The his_addr is referred to determine just an address family, here.
 When a remote address is an IPv4-mapped IPv6 address, a local address
 is as well.  So, it should be okay.

When a remote address is an IPv4-mapped IPv6 address, why the local IPv6
address must be of the same type and cannot be any regular IPv6 address?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SSH login takes very long time...sometimes

[Rostislav Krasny]

On Mon, 27 Feb 2006 02:49:15 +0900
Hajimu UMEMOTO [EMAIL PROTECTED] wrote:

 Hi,
 
  On Sun, 26 Feb 2006 17:40:19 +0200
  Rostislav Krasny [EMAIL PROTECTED] said:
 
 rosti It will require to specify a virtual host for each address or to use
 rosti hostname with multiple addresses only once. Specifying a virtual host 
 by
 rosti a hostname and registering multiple hostname's addresses in /etc/hosts
 rosti should not be confusing, IMHO. If the addresses are already registered
 rosti on DNS, the work is even simpler.
 
 rosti Even specifying virtual hosts by addresses should not be confusing,
 rosti because IPv4-mapped IPv6 address and the IPv4-mapped itself are
 rosti certainly not the same, although they are mapped each to other. Indeed,
 rosti someone could want to specify different virtual ftp hosts for IPv4 and
 rosti mapped to it IPv6 addresses. For example to use different motd, welcome
 rosti or statfile files.
 
 Then, you are already confused.
 
 rosti When a remote address is an IPv4-mapped IPv6 address, why the local 
 IPv6
 rosti address must be of the same type and cannot be any regular IPv6 
 address?
 
 Because, the connection uses an IPv4 to communicate with each other.
 There is two representation for one IPv4 address; native IPv4 address
 and an IPv4-mapped IPv6 address.  It is thorny thing.

You may be right and I'm confused. I don't have much experience with
IPv6. I just thought that any unicast IPv6 host, even IPv4-mapped IPv6
host, can communicate with any other unicast IPv6 host, including
non-IPv4-mapped IPv6 host. Could you please suggest a good
comprehensive article on the Web about IPv4-mapped IPv6 addresses and
their usage? By the way, why you don't do the address type test in a
daemon mode of ftpd?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SSH login takes very long time...sometimes

[Rostislav Krasny]

On Sat, 25 Feb 2006 16:28:50 +0900
Hajimu UMEMOTO [EMAIL PROTECTED] wrote:

 Hi,
 
  On Sat, 25 Feb 2006 02:42:46 +0200
  Rostislav Krasny [EMAIL PROTECTED] said:
 
 rosti I've found the problem in both: ftpd(8) and ftp(1). In the ftpd(8) a
 rosti getaddrinfo() is called in two places with hints.ai_socktype == 0 and
 rosti hints.ai_family == PF_UNSPEC. In the ftp(1) a command reply timeout is
 rosti only 60 seconds. Those things are what I've changed to fix the problem.
 rosti Two diffs are attached to this email. The ftpd.c.diff extends -4 and -6
 rosti ftpd options. So if this patch is good, the ftpd(8) manual page and the
 rosti default /etc/inetd.conf should also be changed appropriately.
 
 For your ftpd.c.diff, I like your idea to reduce redundant query.  It
 is enough to query just appropriate address family.  In inetd mode, we
 know the address family already.  So, we don't need to rely on the
 -4/-6 option.  The following diff is against ftpd.c with your patch
 applied:
 
 --- ftpd.c.rosti  Sat Feb 25 15:41:52 2006
 +++ ftpd.cSat Feb 25 16:01:46 2006
 @@ -423,10 +423,6 @@ main(int argc, char *argv[], char **envp
   }
   }
  
 -#ifdef VIRTUAL_HOSTING
 - inithosts(family);
 -#endif
 -
   if (daemon_mode) {
   int *ctl_sock, fd, maxfd = -1, nfds, i;
   fd_set defreadfds, readfds;
 @@ -456,6 +452,10 @@ main(int argc, char *argv[], char **envp
   sa.sa_handler = reapchild;
   (void)sigaction(SIGCHLD, sa, NULL);
  
 +#ifdef VIRTUAL_HOSTING
 + inithosts(family);
 +#endif
 +
   /*
* Open a socket, bind it to the FTP port, and start
* listening.
 @@ -525,6 +525,14 @@ main(int argc, char *argv[], char **envp
   syslog(LOG_ERR, getpeername (%s): %m,argv[0]);
   exit(1);
   }
 +
 +#ifdef VIRTUAL_HOSTING
 + family = his_addr.su_family;
 + if (his_addr.su_family == AF_INET6 
 + IN6_IS_ADDR_V4MAPPED(his_addr.su_sin6.sin6_addr))
 + family = AF_INET;
 + inithosts(family);
 +#endif
   }
  
  gotchild:

family = his_addr.su_family; is really a good idea. But what is the
reason to check if IPv6 address of a remote client is IPv4 mapped and
assign AF_INET to a 'family' when that's true? The inithosts() doesn't
lookup for that address but for the server's hostname and optionally
virtual server's hostnames from /etc/ftphosts. I think it's unnecessary
and can even produce problems. IMHO inithosts(family); could be
called right after the family = his_addr.su_family; line.

 For ftp.c.diff, how about considering adding new option for timeout?

That was what I thought about when wrote my previous email. What name
could be good for that option? Is -c seconds (ftp Command reply
timeout in seconds) a good one?

 However, I'm still in doubt.  I cannot think it is usual situation
 that there are unreachable IP addresses in /etc/resolv.conf.

It is unusual situation but it can happen. Otherwise this duscussion
was not started.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SSH login takes very long time...sometimes

[Rostislav Krasny]

On Sat, 25 Feb 2006 17:22:07 +0300
Yar Tikhiy [EMAIL PROTECTED] wrote:

  However I was unable to connect by ftp, even with only one unreachable
  name server in resolv.conf. I got following error:
  
  421 Service not available, remote server timed out. Connection closed
  
  I've found the problem in both: ftpd(8) and ftp(1). In the ftpd(8) a
  getaddrinfo() is called in two places with hints.ai_socktype == 0 and
  hints.ai_family == PF_UNSPEC. In the ftp(1) a command reply timeout is
  only 60 seconds. Those things are what I've changed to fix the problem.
  Two diffs are attached to this email. The ftpd.c.diff extends -4 and -6
  ftpd options. So if this patch is good, the ftpd(8) manual page and the
  default /etc/inetd.conf should also be changed appropriately.
 
 Could you explain please how your patch would affect ftpd(8) semantics
 visible to the user?

ftpd(8) has -4 and -6 options, which originally are used in daemon mode
only. With my patch they are used in inetd mode too. But Hajimu showed
me that in the inetd mode the 'family' variable could be assigned
according to remote client's address family. Please read my recent reply
to his email.

  Although I changed two getaddrinfo() calls in ftpd.c, only first of
  them is really called on default FreeBSD configuration,
  when /etc/ftphosts isn't existing yet. So there might be a need of
  additional increase of the command reply timeout in ftp.c. Or better if
  this timeout could be configurable by some new ftp(1) option, with 120
  seconds by default.
 
  --- libexec/ftpd/ftpd.c.origWed Feb  8 18:54:05 2006
  +++ libexec/ftpd/ftpd.c Sat Feb 25 00:30:26 2006
  @@ -239,7 +239,7 @@
  }
   
   #ifdef VIRTUAL_HOSTING
  -static void inithosts(void);
  +static void inithosts(int);
   static void selecthost(union sockunion *);
   #endif
   static void ack(char *);
  @@ -424,7 +424,7 @@
  }
   
   #ifdef VIRTUAL_HOSTING
  -   inithosts();
  +   inithosts(family);
   #endif
   
  if (daemon_mode) {
  @@ -663,7 +663,7 @@
*/
   
   static void
  -inithosts(void)
  +inithosts(int family)
   {
  int insert;
  size_t len;
  @@ -689,7 +689,8 @@
   
  memset(hints, 0, sizeof(hints));
  hints.ai_flags = AI_CANONNAME;
  -   hints.ai_family = AF_UNSPEC;
  +   hints.ai_family = family;
  +   hints.ai_socktype = SOCK_STREAM;
  if (getaddrinfo(hrp-hostname, NULL, hints, res) == 0)
  hrp-hostinfo = res;
  hrp-statfile = _PATH_FTPDSTATFILE;
  @@ -759,9 +760,10 @@
  /* NOTREACHED */
  }
   
  -   hints.ai_flags = 0;
  -   hints.ai_family = AF_UNSPEC;
  +   /* If no flag, assign hints.ai_flags to zero! */
 
 Sorry, but I don't understand the purpose of this comment here.

The original code looked like that:

hints.ai_flags = 0;
hints.ai_family = AF_UNSPEC;
hints.ai_flags = AI_PASSIVE;

It looked like someone wanted to say to future developers: if you don't
whant hints.ai_flags = AI_PASSIVE keep the hints.ai_flags = 0.
My comment might be not well formulated or even unnecessary, sorry.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SSH login takes very long time...sometimes

[Rostislav Krasny]

On Sun, 26 Feb 2006 01:41:28 +0900
Hajimu UMEMOTO [EMAIL PROTECTED] wrote:

 Hi,
 
  On Sat, 25 Feb 2006 16:46:48 +0200
  Rostislav Krasny [EMAIL PROTECTED] said:
 
 rosti family = his_addr.su_family; is really a good idea. But what is the
 rosti reason to check if IPv6 address of a remote client is IPv4 mapped and
 rosti assign AF_INET to a 'family' when that's true? The inithosts() doesn't
 rosti lookup for that address but for the server's hostname and optionally
 rosti virtual server's hostnames from /etc/ftphosts. I think it's unnecessary
 rosti and can even produce problems. IMHO inithosts(family); could be
 rosti called right after the family = his_addr.su_family; line.
 
 No, when a local address of a connection is an IPv4-mapped IPv6
 address, selecthost() does test it as a native IPv4 address.  So, we
 need to lookup hostnames as an IPv4 in inithosts().  Please refer
 selecthost() for detail.

As far as I understand the code of selecthost() it walks through linked
lists of known virtual hosts and their addresses and compares the
addresses to a local address of connected socket. This way it tries to
find - configuration of what virtual host should be used. There is an
additional comparison that seems like a workaround for misconfigured
virtual host that can be resolved only to IPv4 address and should be
used on IPv4-mapped IPv6 address. If virtual hosts are properly
configured that hack is not needed, IMHO.

Anyway selecthost() is called with local socket name and it checks a
local address, while his_addr.su_sin6.sin6_addr is a remote address.
Local and remote hosts have same address families but not same
addresses.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SSH login takes very long time...sometimes

[Rostislav Krasny]

On Fri, 24 Feb 2006 11:50:25 +0900
Hajimu UMEMOTO [EMAIL PROTECTED] wrote:

 Hi,

Hello

  On Thu, 23 Feb 2006 23:57:27 +0200
  Rostislav Krasny [EMAIL PROTECTED] said:
 
 rosti Your patch fixed the problem, thank you.
 
 Thank you for testing.  I'll commit it later.

Excellent! What about RES_DFLRETRY decreasing from 4 to 2? Does it need
more testing or discussion?

 rosti But during my tests I've found
 rosti another form of doubling bug in getaddrinfo(). To test the 
 getaddrinfo()
 rosti behavior I used a program that is attached to this email.
 rosti If hints.ai_socktype == 0 then the getaddrinfo() does the lookup twice,
 rosti even if DNS is reachable. If the latter is the case, returned linked
 rosti list is twice as large than it should be. The hints.ai_socktype seems
 rosti to have the same influence when hints.ai_family is PF_INET6 or
 rosti PF_UNSPEC too.
 
 No, it is expected behavior of getaddrinfo(3).  If hints.ai_socktype
 is zero, getaddrinfo(3) returns the entries for all available
 socktypes.  Though getaddrinfo(3) returns doubled linkd list,
 getaddrinfo(3) does DNS lookup just once for all.  If you don't want
 it, you need to specify appropriate socktype explicitly.

Ok. It was just not clear when I read the manual and saw, by tcpdump, two
for example 'A? yahoo.com.' requests to a reachable DNS.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SSH login takes very long time...sometimes

[Rostislav Krasny]

On Fri, 24 Feb 2006 20:40:07 +0300
Yar Tikhiy [EMAIL PROTECTED] wrote:

 To Rostislav: Could you do now, with the resolver fixes applied,
 the following experiment: find how many dead nameservers in resolv.conf
 it takes for sshd to start timing out a connection to it?  There
 is still your PR open on this issue, so we should see whether
 the default for LoginGraceTime needs a change, too.  Thanks!

The maximum number of name servers those the resolver will work with is
MAXNS, which currently is 3. With three unreachable name servers in
resolv.conf I successfully connected from other, not patched, FreeBSD
6.1-PRERELEASE by ssh without touching LoginGraceTime. I've got the
password prompt after about 48.5 seconds, according to a stop watch in
my cell phone :-)

I also tested telnet connection and it worked properly in that
situation.

However I was unable to connect by ftp, even with only one unreachable
name server in resolv.conf. I got following error:

421 Service not available, remote server timed out. Connection closed

I've found the problem in both: ftpd(8) and ftp(1). In the ftpd(8) a
getaddrinfo() is called in two places with hints.ai_socktype == 0 and
hints.ai_family == PF_UNSPEC. In the ftp(1) a command reply timeout is
only 60 seconds. Those things are what I've changed to fix the problem.
Two diffs are attached to this email. The ftpd.c.diff extends -4 and -6
ftpd options. So if this patch is good, the ftpd(8) manual page and the
default /etc/inetd.conf should also be changed appropriately.

Although I changed two getaddrinfo() calls in ftpd.c, only first of
them is really called on default FreeBSD configuration,
when /etc/ftphosts isn't existing yet. So there might be a need of
additional increase of the command reply timeout in ftp.c. Or better if
this timeout could be configurable by some new ftp(1) option, with 120
seconds by default.
--- libexec/ftpd/ftpd.c.origWed Feb  8 18:54:05 2006
+++ libexec/ftpd/ftpd.c Sat Feb 25 00:30:26 2006
@@ -239,7 +239,7 @@
}
 
 #ifdef VIRTUAL_HOSTING
-static void inithosts(void);
+static void inithosts(int);
 static void selecthost(union sockunion *);
 #endif
 static void ack(char *);
@@ -424,7 +424,7 @@
}
 
 #ifdef VIRTUAL_HOSTING
-   inithosts();
+   inithosts(family);
 #endif
 
if (daemon_mode) {
@@ -663,7 +663,7 @@
  */
 
 static void
-inithosts(void)
+inithosts(int family)
 {
int insert;
size_t len;
@@ -689,7 +689,8 @@
 
memset(hints, 0, sizeof(hints));
hints.ai_flags = AI_CANONNAME;
-   hints.ai_family = AF_UNSPEC;
+   hints.ai_family = family;
+   hints.ai_socktype = SOCK_STREAM;
if (getaddrinfo(hrp-hostname, NULL, hints, res) == 0)
hrp-hostinfo = res;
hrp-statfile = _PATH_FTPDSTATFILE;
@@ -759,9 +760,10 @@
/* NOTREACHED */
}
 
-   hints.ai_flags = 0;
-   hints.ai_family = AF_UNSPEC;
+   /* If no flag, assign hints.ai_flags to zero! */
hints.ai_flags = AI_PASSIVE;
+   hints.ai_family = family;
+   hints.ai_socktype = SOCK_STREAM;
if (getaddrinfo(vhost, NULL, hints, res) != 0)
goto nextline;
for (ai = res; ai != NULL  ai-ai_addr != NULL;
--- contrib/lukemftp/src/ftp.c.orig Tue May 17 06:11:25 2005
+++ contrib/lukemftp/src/ftp.c  Sat Feb 25 01:42:19 2006
@@ -406,7 +406,7 @@
for (line = 0 ;; line++) {
dig = n = code = 0;
cp = current_line;
-   while (alarmtimer(60),((c = getc(cin)) != '\n')) {
+   while (alarmtimer(120),((c = getc(cin)) != '\n')) {
if (c == IAC) { /* handle telnet commands */
switch (c = getc(cin)) {
case WILL:
@@ -447,7 +447,7 @@
if (verbose) {
if (reply_timeoutflag)
fputs(
-421 Service not available, remote server timed out. Connection closed\n,
+421 Service not available, remote server timed out. Connection closed.\n,
ttyout);
else if (reply_abrtflag)
fputs(
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SSH login takes very long time...sometimes

[Rostislav Krasny]

On Thu, 23 Feb 2006 02:08:17 +0900
Hajimu UMEMOTO [EMAIL PROTECTED] wrote:

 Hi,
 
  On Wed, 22 Feb 2006 02:44:30 +0200
  Rostislav Krasny [EMAIL PROTECTED] said:
 
 rosti On Tue, 21 Feb 2006 19:59:59 +0300
 rosti Yar Tikhiy [EMAIL PROTECTED] wrote:
 
 rosti I forgot that a search resolver(5) parameter is useless for reverse
 rosti resolving. But that doubling of name-IP requests with an empty (or
 rosti root, according to resolver(5)) domain in the search is still a bug,
 rosti IMHO. Although it shouldn't affect the sshd.
 
 I looked BIND9's resolver, and took the related part into our
 resolver.  However, it seems to me that there is still same issue in
 BIND9's resolver.  So, I change more bit.  Please try the following
 patch and let me know the result:

Your patch fixed the problem, thank you. But during my tests I've found
another form of doubling bug in getaddrinfo(). To test the getaddrinfo()
behavior I used a program that is attached to this email.
If hints.ai_socktype == 0 then the getaddrinfo() does the lookup twice,
even if DNS is reachable. If the latter is the case, returned linked
list is twice as large than it should be. The hints.ai_socktype seems
to have the same influence when hints.ai_family is PF_INET6 or
PF_UNSPEC too.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SSH login takes very long time...sometimes

[Rostislav Krasny]

On Tue, 21 Feb 2006 19:59:59 +0300
Yar Tikhiy [EMAIL PROTECTED] wrote:

 On Sun, Feb 19, 2006 at 10:57:01PM +0200, Rostislav Krasny wrote:
  On Sun, 19 Feb 2006 13:49:12 +0300
  Yar Tikhiy [EMAIL PROTECTED] wrote:
  
   On Sat, Feb 18, 2006 at 01:20:29AM +0200, Rostislav Krasny wrote:
On Thu, 16 Feb 2006 08:35:18 +0100
[EMAIL PROTECTED] (Dag-Erling Sm??rgrav) wrote:

 David Malone [EMAIL PROTECTED] writes:
  I did once mail des@ to ask him if he'd mind me changing the default
  login timeout for sshd to be (say) 5 minutes rather than 1 minute,
  but I think he was busy at the time. Judging by the PR mentioned
  above it should be at least 2m30s by default. Des, would you mind
  this change being made?
 
 No objection, just let me see the patch first.

In conjunction to what David had proposed, what do you think about
decreasing the RES_DFLRETRY from 4 to 2, like in other systems and in
BIND9's resolver?
   
   Could you try this change in your system and report the exact
   results, such as output from tcpdump?  That is how we could judge
   the change in question...  Or were the results reported already?
  
  Ok, I rebuilded the world and the kernel with this change and tested it
  with tcpdump and a small program from the bin/62139 PR. During the test
  I saw two A? yahoo.com. requests, then two A? yahoo.com.lan.
  requests and that all taked only 30 seconds for gethostbyname() to give
  up with one unreachable DNS. Now it looks better than before.
  
  But I think there is still a bug. If I change hostname from saturn.lan
  to just saturn I see 4 A? yahoo.com. requests, like in the PR with
  options attemts:2. Why it tries to repeat the requests when the domain
  name is empty and so is the search list by default? That is the
  doubling I had wrote about in the PR.
 
 The doubling happens only to name-IP lookups, but not to reverse
 lookups, according to my observations.  Therefore DNS requests by
 sshd and friends shouldn't be affected. However, sshd will make 3
 (!) lookups on the client IP address by itself.  I wonder if there
 is a good reason for that.

I forgot that a search resolver(5) parameter is useless for reverse
resolving. But that doubling of name-IP requests with an empty (or
root, according to resolver(5)) domain in the search is still a bug,
IMHO. Although it shouldn't affect the sshd.

This time I used following program with a couple of date(1) to measure
the reverse lookup failure time with one unreachable DNS:

#include sys/types.h
#include sys/socket.h
#include netinet/in.h
#include arpa/inet.h
#include netdb.h
#include stdio.h

int main(int argc, char *argv[])
{
struct hostent *ps_hostent;
struct in_addr b_addr;

if (argc == 2  inet_aton(argv[1], b_addr)) {
ps_hostent = gethostbyaddr((void *)b_addr, 4, AF_INET);
if (ps_hostent != NULL) {
printf(%s\n, ps_hostent-h_name);
} else {
herror(argv[1]);
}
} else {
fputs(No valid argument.\n, stderr);
}
return 0;
}

On my system, builded with RES_DFLRETRY defined as 2, it taked only 15
seconds for gethostbyaddr() to fail, after two DNS requests. To emulate
the old behavior I added options attempts:4 to /etc/resolv.conf. With
that configuration it taked already one minute more (1:15) for
gethostbyaddr() to fail. Therefore three calls of gethostbyaddr(), when
RES_DFLRETRY defined as 2, are better than even one call of the same
function when RES_DFLRETRY defined as 4.

 I also found that the second round of the doubling would use the
 first domain from `search' line if it is in resolv.conf.  The rest
 of domains specified on `search' line are ignored.  Hoping this
 observation will come useful, should somebody want to fix this bug.

Alternatively FreeBSD could switch to a BIND9's resolver, like NetBSD
did in 2004. BIND9 is already in the base system.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SSH login takes very long time...sometimes

[Rostislav Krasny]

On Thu, 16 Feb 2006 08:35:18 +0100
[EMAIL PROTECTED] (Dag-Erling Smørgrav) wrote:

 David Malone [EMAIL PROTECTED] writes:
  I did once mail des@ to ask him if he'd mind me changing the default
  login timeout for sshd to be (say) 5 minutes rather than 1 minute,
  but I think he was busy at the time. Judging by the PR mentioned
  above it should be at least 2m30s by default. Des, would you mind
  this change being made?
 
 No objection, just let me see the patch first.

In conjunction to what David had proposed, what do you think about
decreasing the RES_DFLRETRY from 4 to 2, like in other systems and in
BIND9's resolver?

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

Re: SSH login takes very long time...sometimes

[Rostislav Krasny]

On 12/27/05, David Malone [EMAIL PROTECTED] wrote:
 On Sun, Dec 25, 2005 at 06:41:57PM +0200, Rostislav Krasny wrote:
  defined as 4. In a case the DNS server isn't responding the
  gethostbyname() makes 8 (eight!) reverse resolving attempts for one
  (!) non-responding DNS server before it returns error. And this is by
  default. All that is still true for my current 6.0-STABLE.
 
  http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/62139
 
  As a workaround I may suggest addind options attempts:2 or even
  options attempts:1 line to the /etc/resolver.conf

 I've often thought that we shouled make the default login timeout
 longer than our DNS timeout, as it means it is hard (or impossible)
 to log in to fix your DNS server when your DNS server is down. It
 is even worse if you don't control some DNS server in the chain
 between the root and the name you're trying to look up.

 I did once mail des@ to ask him if he'd mind me changing the default
 login timeout for sshd to be (say) 5 minutes rather than 1 minute,
 but I think he was busy at the time. Judging by the PR mentioned
 above it should be at least 2m30s by default.

I think the RES_DFLRETRY should also be decreased from 4 to 2, as it
is defined in most of other systems. By the way, BIND9, that is a part
of the FreeBSD base system, has its own resolver, where the
RES_DFLRETRY defined as 2 (ses below):

 grep RES_DFLRETRY /usr/src/contrib/bind9/lib/bind/include/resolv.h
#define RES_DFLRETRY2   /* Default #/tries. */
 grep RES_DFLRETRY /usr/include/resolv.h
#define RES_DFLRETRY4   /* retries per each name server */

And doubling of this number of retries by functions like
gethostbyname() is also mysterious for me yet.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SSH login takes very long time...sometimes

[Rostislav Krasny]

Hi,

I had submitted a bin/62139 PR because of the same problem about a
year ago. I still think there is a bug somewhere in a resolver(3)
library or in libc functions like gethostbyname(). Because of this bug
the gethostbyname() doubles the number of its reverse resolving
requests, in a case the DNS server isn't responding. The other reason
for very long waiting is a default configuration of resolver(5). In
most other systems RES_DFLRETRY is defined as 2, but in FreeBSD it is
defined as 4. In a case the DNS server isn't responding the
gethostbyname() makes 8 (eight!) reverse resolving attempts for one
(!) non-responding DNS server before it returns error. And this is by
default. All that is still true for my current 6.0-STABLE.

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

As a workaround I may suggest addind options attempts:2 or even
options attempts:1 line to the /etc/resolver.conf
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Strange lines in dmesg of 6.0-RC1

[Rostislav Krasny]

Hi there,

I didn't check the dmesg messages of 6.0 too closely before I've
upgraded to 6.0-RC1 and accidentally found two strange lines about
$PIR in the following chunk of the dmesg:

pcib0: Host to PCI bridge pcibus 0 on motherboard
pir0: PCI Interrupt Routing Table: 6 Entries on motherboard
pci0: PCI bus on pcib0
$PIR: No matching entry for 0.7.INTD
agp0: VIA 82C597 (Apollo VP3) host to PCI bridge mem 0xd800-0xdbff at
device 0.0 on pci0
pcib1: PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
$PIR: ROUTE_INTERRUPT failed.
pci1: display, VGA at device 0.0 (no driver attached)
isab0: PCI-ISA bridge at device 7.0 on pci0

All devices of this system work fine with 6.0 (previous betas and
current RC). ACPI is disabled. I can send the full dmesg or full
verbose dmesg output, if you need. I'm just interesting, are those two
lines showing any potential problem that others may experience on
different hardware?

For example, in the freebsd-stable@ mailing list archive I've found a
Michel Talon's report about running 6.0-RC1 with RealTek 8029 based
NIC under qemu:

http://docs.freebsd.org/cgi/mid.cgi?20051012094243.GA48295

I have the same NIC made by Genius that works fine on 6.0-RC1, not under qemu:

ed0: RealTek 8029 port 0xec00-0xec1f irq 9 at device 10.0 on pci0
ed0: Ethernet address: 00:c0:df:f3:8a:56
ed0: type NE2000 (16 bit)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

strange atacontrol output in 5.4-RC1 and 5.4-RC2

[Rostislav Krasny]

Hi,

I have two i386 computers with close configuration of ATA disks:

mercury# atacontrol list
ATA channel 0:
Master:  ad0 WDC AC14300R/17.01J17 ATA/ATAPI revision 4
Slave:   no device present
ATA channel 1:
Master:  ad2 FUJITSU MPB3021ATU/2011 ATA/ATAPI revision 3
Slave:  acd0 TOSHIBA CD-ROM XM-6602B/1017 ATA/ATAPI revision 0

vega# atacontrol list
ATA channel 0:
Master:  ad0 WDC AC28400R/17.01J17 ATA/ATAPI revision 4
Slave:   no device present
ATA channel 1:
Master:  ad2 WDC AC22100H/12.07H12 ATA/ATAPI revision 0
Slave:   ad3 Seagate Technology 1275MB - ST31276A/1.37 ATA/ATAPI
revision 2

Mercury is Intel SE440BX-2 motherboard based computer with FreeBSD
5.4-RC2. Vega is Intel 430TX chipset based computer with FreeBSD
5.4-RC1. When I run ' atacontrol cap 0 0' I get the same last part of
the output:

Feature  Support  EnableValue   Vendor
write cacheyes  yes
read ahead yes  yes
dma queued no   no  0/0x00
SMART  yes  yes
microcode download no   no
security   no   yes
power management   yes  yes
advanced power management  no   no  0/0x00
automatic acoustic management  no   no  0/0x00  0/0x00

How could the security feature be not supported and enabled at the same time?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

two mysterious files in RELENG_5_4

[Rostislav Krasny]

Hello all.

I have FreeBSD 5.4-RC1 installed from FTP. Today I ran cvsup to get
the latest RELENG_5_4 src-all. I've seen two strange files were
checkouted by cvsup:

 Checkout src/installworld_newk
 Checkout src/installworld_oldk

I don't see those files on
http://www.freebsd.org/cgi/cvsweb.cgi/src/?only_with_tag=RELENG_5_4
but I see them on http://www.freebsd.org/cgi/cvsweb.cgi/src/Attic/
According to the cvsweb logs those files were removed in HEAD but
still exist in RELENG_5_4. But why I don't see them on the cvsweb by
the first URL and why they didn't exist in my 5.4-RC1 before cvsup?
Or, if they were removed in the RELENG_5_4 too, why cvsup checkouted
them today?

Following is my cvsup supfile:

# Defaults that apply to all the collections
#
*default host=cvsup.FreeBSD.org
*default base=/var/db
*default prefix=/usr
*default release=cvs tag=RELENG_5_4
*default delete use-rel-suffix
*default compress

## Main Source Tree.
#
src-all
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: kern/67636 PR again?

[Rostislav Krasny]

On Fri, 4 Mar 2005 23:50:15 -0800 (PST)
Doug White [EMAIL PROTECTED] wrote:
 On Thu, 3 Mar 2005, Rostislav Krasny wrote:
 
  Hello there.
 
  Although the kern/67636 PR was closed before FreeBSD 5.3-RELEASE,
  I'm experiencing exactly the same problem on my FreeBSD
  5.3-RELEASE-p5:
 
  saturn# ls -al /boot/kernel/ipl.ko
  -r-xr-xr-x  1 root  wheel  92883 Jan 17 12:18 /boot/kernel/ipl.ko
  saturn# kldload -v /boot/kernel/ipl.ko
  kldload: can't load /boot/kernel/ipl.ko: No such file or directory
  saturn# dmesg | tail -1
  link_elf: symbol in6_cksum undefined
 
  And following is the contents of my kernel build configuration file.
  As you can see I've disabled INET6 but enabled IPFIREWALL and
  IPDIVERT for some other use. Before trying ipl I was using ipfw with
  natd.
 
 ... and ipl, as configured stock, requires INET6. Compile your kernel
 with INET6 or manually compile the ipfilter module to remove the
 requirement:
 
 cd /sys/modules/ipfilter
 make cleandir
 make obj
 make -DNOINET6
 make install
 
 You'll have to do this anytime you rebuild your kernel, unless you add
 a line to /etc/make.conf like
 
 NOINET6=yes
 
 but I'm not sure what effect that will have on other code.

Defining NOINET6 in the /etc/make.conf disables building IPv6 related
programs and libraries during buildworld. I wonder why kernel code is
using this environment variable without checking its own INET6 one too?

Take a look on following locations:

/usr/src/sys grep -r NOINET6 *
contrib/ipfilter/netinet/ip_compat.h:   !defined(NOINET6)) || \
modules/ipfilter/Makefile:.if !defined(NOINET6)
modules/pf/Makefile:.if defined(NOINET6)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

kern/67636 PR again?

[Rostislav Krasny]

Hello there.

Although the kern/67636 PR was closed before FreeBSD 5.3-RELEASE,
I'm experiencing exactly the same problem on my FreeBSD 5.3-RELEASE-p5:

saturn# ls -al /boot/kernel/ipl.ko
-r-xr-xr-x  1 root  wheel  92883 Jan 17 12:18 /boot/kernel/ipl.ko
saturn# kldload -v /boot/kernel/ipl.ko
kldload: can't load /boot/kernel/ipl.ko: No such file or directory
saturn# dmesg | tail -1
link_elf: symbol in6_cksum undefined

And following is the contents of my kernel build configuration file.
As you can see I've disabled INET6 but enabled IPFIREWALL and IPDIVERT
for some other use. Before trying ipl I was using ipfw with natd.


machine i386
cpu I586_CPU
cpu I686_CPU
ident   MYKERNEL

options SCHED_4BSD  # 4BSD scheduler
options INET# InterNETworking
options FFS # Berkeley Fast Filesystem
options SOFTUPDATES # Enable FFS soft updates support
options UFS_ACL # Support for access control lists
options UFS_DIRHASH # Improve performance on big directories
options MD_ROOT # MD is a potential root device
options NFSCLIENT   # Network Filesystem Client
options NFSSERVER   # Network Filesystem Server
options NFS_ROOT# NFS usable as /, requires NFSCLIENT
options MSDOSFS # MSDOS Filesystem
options CD9660  # ISO 9660 Filesystem
options PROCFS  # Process filesystem (requires PSEUDOFS)
options PSEUDOFS# Pseudo-filesystem framework
options GEOM_GPT# GUID Partition Tables.
options COMPAT_43   # Compatible with BSD 4.3 [KEEP THIS!]
options COMPAT_FREEBSD4 # Compatible with FreeBSD4
options SCSI_DELAY=15000# Delay (in ms) before probing SCSI
options KTRACE  # ktrace(1) support
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time
extensions
options KBD_INSTALL_CDEV# install a CDEV entry in /dev
options AHC_REG_PRETTY_PRINT# Print register bitfields in debug
# output.  Adds ~128k to driver.
options AHD_REG_PRETTY_PRINT# Print register bitfields in debug
# output.  Adds ~215k to driver.
options ADAPTIVE_GIANT  # Giant mutex is adaptive.


options IPFIREWALL  #firewall
options IPDIVERT#divert sockets


device  apic# I/O APIC

# Bus support.  Do not remove isa, even if you have no isa slots
device  isa
device  pci

# Floppy drives
device  fdc

# ATA and ATAPI devices
device  ata
device  atadisk # ATA disk drives
device  atapicd # ATAPI CDROM drives
options ATA_STATIC_ID   # Static device numbering

# atkbdc0 controls both the keyboard and the PS/2 mouse
device  atkbdc  # AT keyboard controller
device  atkbd   # AT keyboard
device  psm # PS/2 mouse

device  vga # VGA video card driver

device  splash  # Splash screen and screen saver support

# syscons is the default console driver, resembling an SCO console
device  sc

# Enable this for the pcvt (VT220 compatible) console driver
#device vt
#optionsXSERVER # support for X server on a vt console
#optionsFAT_CURSOR  # start with block cursor

device  agp # support several AGP chipsets

# Floating point support - do not disable.
device  npx

# Power management support (see NOTES for more options)
#device apm
# Add suspend/resume support for the i8254.
device  pmtimer

# Serial (COM) ports
device  sio # 8250, 16[45]50 based serial ports

# Parallel port
device  ppc
device  ppbus   # Parallel port bus (required)
device  lpt # Printer
device  ppi # Parallel port interface device
#device vpo # Requires scbus and da

# PCI Ethernet NICs that use the common MII bus controller code.
# NOTE: Be sure to keep the 'device miibus' line in order to use these
# NICs!
device  miibus  # MII bus support
device  xl  # 3Com 3c90x (``Boomerang'', ``Cyclone'')

# ISA Ethernet NICs.  pccard NICs included.
# 'device ed' requires 'device miibus'
device  ed  # NE[12]000, SMC Ultra, 3c503, DS8390 cards

# Pseudo devices.
device  loop 

kbdcontrol(1) may hang the keyboard

[Rostislav Krasny]

Hello all.

Please consider following scenario:

1. go to your console and make sure the Caps Lock is not active
2. run 'kbdcontrol -l ru.koi8-r'
3. run 'kbdcontrol -l us.iso'
4. run 'kbdcontrol -l ru.koi8-r' again
5. press the [Caps Lock] button
6. use up and down arrow keys to get recently entered 'kbdcontrol -l
us.iso' and press [Enter]

At this step my keyboard hangs totally, however the system could be
accessed by ssh. This is 5.3-RELEASE-p5 on i386. I beleive the same hangs
could happen with other keymaps those use the [Caps Lock] key as a switch key.



__ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: sometimes 5.3-RELEASE-p5 is stuck at the last steps of shutdown

[Rostislav Krasny]

--- Michael Nottebrock [EMAIL PROTECTED] wrote:
 Rostislav Krasny wrote:
 
  Hello all.
  
  I use FreeBSD 5.3-RELEASE-p5 on i386. Sometimes my system is stuck at
 the
  last steps of shutdown. Following quoting is what I saw yesterday when
 my
  system was stuck again (the last lines):
  
  init: some processes would not die; ps axl advised
 
 You should try to find out what's causing that. I personally got this a
 few 
 times, too, when a mount command got badly stuck because trouble with the
 hdd.

I don't know how could I find, during the shutdown, what are those
unkillable processes. I didn't find anything suspicious in
/var/log/messages. Could init(8) be configured/patched to print/log a list
of such unkillable processes during the shutdown?

There are following PATA devices in this box:
ad0: 14649MB IBM-DTLA-307015/TX2OA5AA [29765/16/63] at ata0-master UDMA33
ad1: 3098MB ST33210A/1.70 [6296/16/63] at ata0-slave UDMA33
ad2: 14324MB IBM-DTLA-307015/TX2DA5AA [29104/16/63] at ata1-master UDMA33
acd0: CDROM SAMSUNG CD-ROM SC-152L/C100 at ata1-slave PIO4
And ACPI is disabled.

In a past ad2 was not physically installed, acd0 was different  and I ran
FreeBSD 5.3-RELEASE (lower patchlevel) on ad1. I had experienced the same
shutdown problem with the same low periodicity. I believe it is not an HDD 
problem.



__ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

sometimes 5.3-RELEASE-p5 is stuck at the last steps of shutdown

[Rostislav Krasny]

Hello all.

I use FreeBSD 5.3-RELEASE-p5 on i386. Sometimes my system is stuck at the
last steps of shutdown. Following quoting is what I saw yesterday when my
system was stuck again (the last lines):

init: some processes would not die; ps axl advised
Waiting (max 60 seconds) for system process `vnlru' to stop... done
Waiting (max 60 seconds) for system process `bufdaemon' to stop... done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining... 2 1 0 0 0 done
No buffers busy after final sync

I've experienced such system stucks after short and also not so short
uptimes. I don't know how to reproduce it for sure. Before that specific
shutdown I ran Xorg 6.8.1 with KDE 3.3.2 but then I quit KDE, quit X and
logged out. I don't use either xdm nor kdm.

On the next boot '/', '/tmp' and '/usr' were declared as not properly
dismounted.

How could the shutdown processing be fixed so it will never stuck?



__ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: hushlogin attribute

[Rostislav Krasny]

--- Lowell Gilbert [EMAIL PROTECTED] wrote:
 Rostislav Krasny [EMAIL PROTECTED] writes:
 
  Yes, there are few words about one should run 'cap_mkdb
  /etc/login.conf' after each change. But this is not what I propose to
  add to the manual page and /etc/login.conf is not a manual page by
  itself. At first I wasn't pay attention to these lines at all because I
  already read the manual and I instinctively wasn't expected to find any
  new information in /etc/login.conf. FreeBSD 4.8 Errata have a much
  better explanation than lines 3 and 5 on /etc/login.conf. Why not to
  add something like that to the login.conf(5) manual page?
 
 That makes sense.  Feel free to submit such a change.

Thanks for suggestion. I submited a docs/75068 PR about that.

  By the way, do you know why hushlogin attribute doesn't work from the
  ~/.login_conf or how it can work from there? Thank you in advance.
 
 I haven't used it in a while, but I thought that one worked.  After
 you rebuild the database, of course.  I'm fairly sure it assumes your
 login session is actually using login(1), though.

Rebuilding the /etc/login.conf.db and building ~/.login_conf.db doesn't
help. If you're interesting, take a look on a bin/75001 PR with my patch of
login(1). BTW that patch also fixes the same problem with nocheckmail
attribute in user's '.login_conf'.



__ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 

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

[PATCH] (was: hushlogin attribute)

[Rostislav Krasny]

The attached patch of login(1) allows hushlogin and nocheckmail attributes
to work from the user's '.login_conf' as well as from the '/etc/login.conf'.



__ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail

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

Re: [PATCH] (was: hushlogin attribute)

[Rostislav Krasny]

--- Ceri Davies [EMAIL PROTECTED] wrote:

 On Sun, Dec 12, 2004 at 02:21:23PM -0800, Rostislav Krasny wrote:
  The attached patch of login(1) allows hushlogin and nocheckmail
  attributes to work from the user's '.login_conf' as well as from the
  '/etc/login.conf'.
 
 It would be a good idea to send-pr this.

Thank you for suggestion. I just sent a PR and its number is bin/75001.



__ 
Do you Yahoo!? 
All your favorites on one personal page – Try My Yahoo!
http://my.yahoo.com 
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: hushlogin attribute

[Rostislav Krasny]

--- Lowell Gilbert [EMAIL PROTECTED] wrote:
 Rostislav Krasny [EMAIL PROTECTED] writes:
 
  --- Rostislav Krasny [EMAIL PROTECTED] wrote:
   Hello.
   
   The hushlogin attribute doesn't work when it is added to me record 
 of
   ~/.login_conf or to default record of /etc/login.conf. However,
 having
   ~/.hushlogin file does its job well. Is it a bug or am I missing
   something?
   
uname -a
   FreeBSD saturn 5.3-RELEASE-p2 FreeBSD 5.3-RELEASE-p2 #1: Fri Dec  3
   13:57:01 IST 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYKERNEL  
   i386
  
  If I run 'cap_mkdb /etc/login.conf' after the /etc/login.conf was
 changed
  the hushlogin attribute works. But I can't find any way to make
 hushlogin
  attribute work from the ~/.login_conf. Running 'cap_mkdb ~/.login_conf'
  doesn't help. Is it possibly to make the hushlogin attribute work from
  ~/.login_conf file?
  
  P.S. IMHO the login.conf(5) manual page should say something about the
  /etc/login.conf.db file and its preferable usage by login(1).
 
 The first eight lines of login.conf cover this quite well.

Yes, there are few words about one should run 'cap_mkdb /etc/login.conf'
after each change. But this is not what I propose to add to the manual page
and /etc/login.conf is not a manual page by itself. At first I wasn't pay
attention to these lines at all because I already read the manual and I
instinctively wasn't expected to find any new information in
/etc/login.conf. FreeBSD 4.8 Errata have a much better explanation than
lines 3 and 5 on /etc/login.conf. Why not to add something like that to the
login.conf(5) manual page?

By the way, do you know why hushlogin attribute doesn't work from the
~/.login_conf or how it can work from there? Thank you in advance.



__ 
Do you Yahoo!? 
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com 
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

hushlogin attribute

[Rostislav Krasny]

Hello.

The hushlogin attribute doesn't work when it is added to me record  of
~/.login_conf or to default record of /etc/login.conf. However, having
~/.hushlogin file does its job well. Is it a bug or am I missing something?

 uname -a
FreeBSD saturn 5.3-RELEASE-p2 FreeBSD 5.3-RELEASE-p2 #1: Fri Dec  3
13:57:01 IST 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYKERNEL  i386



__ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
http://info.mail.yahoo.com/mail_250
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: hushlogin attribute

[Rostislav Krasny]

--- Rostislav Krasny [EMAIL PROTECTED] wrote:
 Hello.
 
 The hushlogin attribute doesn't work when it is added to me record  of
 ~/.login_conf or to default record of /etc/login.conf. However, having
 ~/.hushlogin file does its job well. Is it a bug or am I missing
 something?
 
  uname -a
 FreeBSD saturn 5.3-RELEASE-p2 FreeBSD 5.3-RELEASE-p2 #1: Fri Dec  3
 13:57:01 IST 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYKERNEL  i386

If I run 'cap_mkdb /etc/login.conf' after the /etc/login.conf was changed
the hushlogin attribute works. But I can't find any way to make hushlogin
attribute work from the ~/.login_conf. Running 'cap_mkdb ~/.login_conf'
doesn't help. Is it possibly to make the hushlogin attribute work from
~/.login_conf file?

P.S. IMHO the login.conf(5) manual page should say something about the
/etc/login.conf.db file and its preferable usage by login(1).




__ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2.1-RC2 kernel panic 12

[Rostislav Krasny]

Dave McCammon wrote:
I'm getting a kernel panic when attempting
to mount an nwfs fs or when doing a 
ncplist s.
When I run 'ncplist s' or 'ncplist c' I get interesting error message:

ncp_initlib: kernel module is old, please recompile it.

And my 5.2.1-RC2 isn't panicing after that commands. This is fresh 
5.2.1-RC2 system installed from official FTP distribution set.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Where is the ports collection of FreeBSD 4.9-RELEASE?

[Rostislav Krasny]

Hello.

I just installed the FreeBSD 4.9-RELEASE by FTP from ftp.freebsd.org. I
have chosen All in Choose Distributions step of sysinstall. During
the installation I got error message about that the ports collection
cannot be located in ftp.freebsd.org. I did few retries but without
success, so I continued the installation. There was no more problem.

Now I see that
ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/4.9-RELEASE/ports/
directory just doesn't exist. I checked few mirrors of ftp.freebsd.org
but .../4.9-RELEASE/ports/ doesn't exist there too. At the same time
.../4.8-RELEASE/ports/ and .../5.1-RELEASE/ports/ exist. As far as I
know, most people uses ISO images and installs FreeBSD from CD. I
didn't check FreeBSD 4.9-RELEASE ISO image but I'm suspecting that
.../4.9-RELEASE/ports/ exist there. Is .../4.9-RELEASE/ports/
non-existence a consequence of some FTP upload problem? Could someone
upload .../4.9-RELEASE/ports/ to fix it?

Thanks

__
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]