Re: Question about KBI change / new feature

[Zhenlei Huang]

> On Aug 23, 2023, at 1:06 AM, Warner Losh  wrote:
> 
> 
> 
> On Mon, Aug 21, 2023 at 9:42 AM Zhenlei Huang  > wrote:
> Hi,
> 
> The https://www.freebsd.org/releases/14.0R/schedule/ 
>  says CURRENT/14 's KBI is 
> froze
> and new features should be avoided.
> 
> I'm working on https://reviews.freebsd.org/D39638 
>  (sysctl(9): Enable vnet sysctl variables 
> be loader tunable)
> and I think it is new feature, but not quite sure whether the KBI changed.
> 
> So,
> 
> 1. Is it a KBI change ?
> 
> IMHO, It's a KPI change, not a KBI breakage. So from that perspective, it's 
> OK.

Thanks for the explanation !

>  
> 2. It is a simple change ( while so far as I know currently only tested by 
> myself on x86 and qemu riscv ), can
> it catch up with 14 ?
> 
> That I'm less sure of. I think it's good, but I'm gun shy about approving / 
> committing vnet things. The review suggests,
> though, there's at least some consensus for having this in the tree.

I always hesitate to PING someone to review ;)

Well I'm going to prepare to commit some of the stack, D41525, D39638, D39852, 
D39866, if no objections.

As for D40127, I have mixed filling about it. It might be too complex (for a 
simple function).
I wonder if we can have per-vnet `loader tunnable` to archive the same goal.

Best regards,
Zhenlei

Re: Question about KBI change / new feature

[Warner Losh]

On Mon, Aug 21, 2023 at 9:42 AM Zhenlei Huang  wrote:

> Hi,
>
> The https://www.freebsd.org/releases/14.0R/schedule/ says CURRENT/14 's
> KBI is froze
> and new features should be avoided.
>
> I'm working on https://reviews.freebsd.org/D39638 (sysctl(9): Enable vnet
> sysctl variables be loader tunable)
> and I think it is new feature, but not quite sure whether the KBI changed.
>
> So,
>
> 1. Is it a KBI change ?
>

IMHO, It's a KPI change, not a KBI breakage. So from that perspective, it's
OK.


> 2. It is a simple change ( while so far as I know currently only tested by
> myself on x86 and qemu riscv ), can
> it catch up with 14 ?


That I'm less sure of. I think it's good, but I'm gun shy about approving /
committing vnet things. The review suggests,
though, there's at least some consensus for having this in the tree.


> Best regards,
> Zhenlei
>
>
>

Re: question on socket server

[Chris]

On 2021-12-15 02:55, Piper H wrote:

But I write this program to listen on port  who sends a random str to
the socket every 0.25 second. And there is no client connecting to the
port. The server just runs there without problem. :( So I am not sure
enough...

use strict;

package MyPackage;
use base qw(Net::Server);


my @fruit=qw(
...
);


sub process_request {
my $self = shift;
$| = 1;
my $max = scalar @fruit;

while (1) {
my $id1 = int(rand($max));
my $str = $fruit[$id1];

print "$str\015\012";
select(undef, undef, undef, 0.25);
}
}


I think it might be easier for you if you have a look at the MILTER
interface to Sendmail. There are a myriad milters written for sendmail.
The entire milter system is (unix) socket driven.
So the examples should prove enlightening? :-)

HTH

-- Chris

MyPackage->run(port => , ipv => '*');

On Wed, Dec 15, 2021 at 6:51 PM Ronald Klop  wrote:


Hi,

Just try it!

I think you will get an error that you are writing to a not-connected
socket.
From "man 2 write":
" [EPIPE]An attempt is made to write to a socket of type
SOCK_STREAM that is not connected to a peer socket."

See also "man 2 send"  and "man 2 socket" for a lot more information.

So it depends a bit on the type of socket you created.

Regards and happy hacking,
Ronald.



*Van:* Piper H 
*Datum:* woensdag, 15 december 2021 07:52
*Aan:* freebsd-current@freebsd.org
*Onderwerp:* question on socket server

Hello

I have little knowledge about socket programming.
I have a question that, if I have made a socket server, listening on a
port. The server prints data to the socket, but there is never a client
connection to the port, and the data is never consumed. What will happen to
the server then? will the OS kernel be flushed by junk bytes?

Thanks for your help.
Piper
--

Re: question on socket server

[Piper H]

Thanks @Ronald Klop 
I changed it to this and it does work:

print "$str\015\012" or return;

Regards


On Wed, Dec 15, 2021 at 7:47 PM Ronald Klop  wrote:

> Hi,
>
> Your program first waits for the first client to connect. So nothing is
> written anywhere.
> You can check by running "nc -v localhost " in another terminal.
> After the first client disconnects it keeps looping in the while and the
> print will return 0 which means failure.
>
> Something like this will improve things.
>
> if (0 == print "test\015\012") {
> return;
> }
>
>
> Regards and happy hacking,
> Ronald.
>
> PS: I think this does not have to do a lot with freebsd-current. Might
> move it to https://lists.freebsd.org/subscription/freebsd-perl or some
> generic perl forum/ML.
>
>
>
> *Van:* Piper H 
> *Datum:* woensdag, 15 december 2021 11:55
> *Aan:* Ronald Klop 
> *CC:* freebsd-current@freebsd.org
> *Onderwerp:* Re: question on socket server
>
> But I write this program to listen on port  who sends a random str to
> the socket every 0.25 second. And there is no client connecting to the
> port. The server just runs there without problem. :( So I am not sure
> enough...
>
> use strict;
>
> package MyPackage;
> use base qw(Net::Server);
>
>
> my @fruit=qw(
> ...
> );
>
>
> sub process_request {
> my $self = shift;
> $| = 1;
> my $max = scalar @fruit;
>
> while (1) {
> my $id1 = int(rand($max));
> my $str = $fruit[$id1];
>
> print "$str\015\012";
> select(undef, undef, undef, 0.25);
> }
> }
>
> MyPackage->run(port => , ipv => '*');
>
> On Wed, Dec 15, 2021 at 6:51 PM Ronald Klop  wrote:
>
>> Hi,
>>
>> Just try it!
>>
>> I think you will get an error that you are writing to a not-connected
>> socket.
>> From "man 2 write":
>> " [EPIPE]An attempt is made to write to a socket of type
>> SOCK_STREAM that is not connected to a peer socket."
>>
>> See also "man 2 send"  and "man 2 socket" for a lot more information.
>>
>> So it depends a bit on the type of socket you created.
>>
>> Regards and happy hacking,
>> Ronald.
>>
>>
>>
>> *Van:* Piper H 
>> *Datum:* woensdag, 15 december 2021 07:52
>> *Aan:* freebsd-current@freebsd.org
>> *Onderwerp:* question on socket server
>>
>> Hello
>>
>> I have little knowledge about socket programming.
>> I have a question that, if I have made a socket server, listening on a
>> port. The server prints data to the socket, but there is never a client
>> connection to the port, and the data is never consumed. What will happen
>> to
>> the server then? will the OS kernel be flushed by junk bytes?
>>
>> Thanks for your help.
>> Piper
>> --
>>
>>

Re: question on socket server

[Ronald Klop via freebsd-current]

Hi,

Your program first waits for the first client to connect. So nothing is written 
anywhere.
You can check by running "nc -v localhost " in another terminal.
After the first client disconnects it keeps looping in the while and the print 
will return 0 which means failure.

Something like this will improve things.

   if (0 == print "test\015\012") {
   return;
   }


Regards and happy hacking,
Ronald.

PS: I think this does not have to do a lot with freebsd-current. Might move it 
to https://lists.freebsd.org/subscription/freebsd-perl or some generic perl 
forum/ML.


Van: Piper H 
Datum: woensdag, 15 december 2021 11:55
Aan: Ronald Klop 
CC: freebsd-current@freebsd.org
Onderwerp: Re: question on socket server


But I write this program to listen on port  who sends a random str to the 
socket every 0.25 second. And there is no client connecting to the port. The 
server just runs there without problem. :( So I am not sure enough...
 
use strict;


package MyPackage;
use base qw(Net::Server);


my @fruit=qw(
...
);


sub process_request {
my $self = shift;
$| = 1;
my $max = scalar @fruit;

while (1) {
my $id1 = int(rand($max));
my $str = $fruit[$id1];

print "$str\015\012";
select(undef, undef, undef, 0.25);
}
}
 
MyPackage->run(port => , ipv => '*');
 
On Wed, Dec 15, 2021 at 6:51 PM Ronald Klop  wrote:


Hi,

Just try it!

I think you will get an error that you are writing to a not-connected socket.
From "man 2 write":
" [EPIPE]An attempt is made to write to a socket of type SOCK_STREAM 
that is not connected to a peer socket."

See also "man 2 send"  and "man 2 socket" for a lot more information.

So it depends a bit on the type of socket you created.

Regards and happy hacking,
Ronald.

 
Van: Piper H 

Datum: woensdag, 15 december 2021 07:52
Aan: freebsd-current@freebsd.org
Onderwerp: question on socket server


Hello

I have little knowledge about socket programming.
I have a question that, if I have made a socket server, listening on a
port. The server prints data to the socket, but there is never a client
connection to the port, and the data is never consumed. What will happen to
the server then? will the OS kernel be flushed by junk bytes?

Thanks for your help.
Piper

Re: question on socket server

[Piper H]

But I write this program to listen on port  who sends a random str to
the socket every 0.25 second. And there is no client connecting to the
port. The server just runs there without problem. :( So I am not sure
enough...

use strict;

package MyPackage;
use base qw(Net::Server);


my @fruit=qw(
...
);


sub process_request {
my $self = shift;
$| = 1;
my $max = scalar @fruit;

while (1) {
my $id1 = int(rand($max));
my $str = $fruit[$id1];

print "$str\015\012";
select(undef, undef, undef, 0.25);
}
}

MyPackage->run(port => , ipv => '*');

On Wed, Dec 15, 2021 at 6:51 PM Ronald Klop  wrote:

> Hi,
>
> Just try it!
>
> I think you will get an error that you are writing to a not-connected
> socket.
> From "man 2 write":
> " [EPIPE]An attempt is made to write to a socket of type
> SOCK_STREAM that is not connected to a peer socket."
>
> See also "man 2 send"  and "man 2 socket" for a lot more information.
>
> So it depends a bit on the type of socket you created.
>
> Regards and happy hacking,
> Ronald.
>
>
>
> *Van:* Piper H 
> *Datum:* woensdag, 15 december 2021 07:52
> *Aan:* freebsd-current@freebsd.org
> *Onderwerp:* question on socket server
>
> Hello
>
> I have little knowledge about socket programming.
> I have a question that, if I have made a socket server, listening on a
> port. The server prints data to the socket, but there is never a client
> connection to the port, and the data is never consumed. What will happen to
> the server then? will the OS kernel be flushed by junk bytes?
>
> Thanks for your help.
> Piper
> --
>
>

Re: question on socket server

[Ronald Klop via freebsd-current]

Hi,

Just try it!

I think you will get an error that you are writing to a not-connected socket.

From "man 2 write":

" [EPIPE]An attempt is made to write to a socket of type SOCK_STREAM 
that is not connected to a peer socket."

See also "man 2 send"  and "man 2 socket" for a lot more information.

So it depends a bit on the type of socket you created.

Regards and happy hacking,
Ronald.


Van: Piper H 
Datum: woensdag, 15 december 2021 07:52
Aan: freebsd-current@freebsd.org
Onderwerp: question on socket server


Hello

I have little knowledge about socket programming.
I have a question that, if I have made a socket server, listening on a
port. The server prints data to the socket, but there is never a client
connection to the port, and the data is never consumed. What will happen to
the server then? will the OS kernel be flushed by junk bytes?

Thanks for your help.
Piper

Re: Question about 'gptzfsboot'

[Thomas Laus]

On 2019-04-29 15:24, Ian Lepore wrote:
> 
> I can't say anything at all about drm or other video driver issues, I'm
> just not knowledgeable about that stuff at all.
> 
> The only thing I was getting at was that the changes I made in r346675
> might make this error stop happening:
> 
>gptzfsboot: error 1 LBA 18446744072709551608
>gptzfsboot: error 1 LBA 1
>gptzfsboot: No ZFS pools located, can't boot
> 
> Emphasis on the "might"... that appears to be an error during probing
> for zfs, and I made some fixes related to probing for zfs.
>
Ian

I saw this gptzfsboot issue 3 times in a row after re-activating r346885
but have not seen it again after at least 12 reboots this afternoon.

It looks like there is an issue with the DRM update or changes to the
kernel between r346544 and r346885 that is causing a separate problem
for me.

Thanks for looking into this.

Tom


-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about 'gptzfsboot'

[Thomas Laus]

On 2019-04-29 14:58, Toomas Soome wrote:
> 
> It means you have different issues - one is about gptzfsboot causing boot 
> problems and apparently it got fixed when you did update the bootcode (the 
> boot partition is global). But also you got bitten by DRM update, and since 
> you had old BE around, you were able to load old kernel.
> 
> Now the question is, is that gptzfsboot issue really fixed or is it just the 
> “warm boot” fix you were seeing earlier too.
>
Toomas:

After activating the snapshot made for r346885, I got the same sort of
gptzfsboot errors that I had seen previously.  After my third attempt, I
was finally given the prompt for my Geli password and proceeded to the
boot menu.  I selected item #3 and went to the loader menu.  I selected
booting from kernel.old and got a successful startup.  I have rebooted
this laptop another dozen times this afternoon and had not had any more
gptzfsboot issues since the three observed when re-activating r346885.

It looks like the changes made by Ian Lepore did not solve my problem
with gptzfsboot.  I will probably start another thread about my issue
with the DRM update.

Thanks for the assistance.

Tom


-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about 'gptzfsboot'

[Ian Lepore]

On Mon, 2019-04-29 at 14:47 -0400, Thomas Laus wrote:
> On 2019-04-29 14:27, Thomas Laus wrote:
> > It was more than a broken console.  All of the other 2 computers
> > that I
> > upgraded to r346885 were essentially 'dead'.  I could not even
> > remotely
> > login to them via ssh.  All of them required a hard power button
> > reset
> > to get into single user mode to let me comment out the rc.conf line
> > that
> > loads the DRM driver.  The computer could successfully boot without
> > DRM
> > activation but would go to a black console screen again with
> > 'startx'.
> > This also required a hard power button shutdown.  I rolled back to
> > r346544 and everything worked again like before.
> > 
> > My disastrous update to r346885 included installing a new
> > gptzfsboot and
> > pmbr in the drive boot record.  I did not try booting an older
> > kernel
> > using the new gptzfsboot.  I was concerned about the lack of ssh
> > login
> > when the computers lost their console, so I just rolled back my
> > system
> > to the last snapshot made a week ago.
> > 
> 
> Ian:
> 
> I re-activated the r346885 BEADM snapshot and booted from my
> 'kernel.old' from r346544 and everything came up OK including 'X'.
> 
> I don't know what that means.  It might be that I have a DRM issue
> instead of a gptzfsboot problem?  Everything except for the kernel is
> now running CURRENT r346885.  I am not using the updated
> drm-current-kmod because I am using the r346544 kernel.old.
> 
> Tom
> 
> 

I can't say anything at all about drm or other video driver issues, I'm
just not knowledgeable about that stuff at all.

The only thing I was getting at was that the changes I made in r346675
might make this error stop happening:

   gptzfsboot: error 1 LBA 18446744072709551608
   gptzfsboot: error 1 LBA 1
   gptzfsboot: No ZFS pools located, can't boot

Emphasis on the "might"... that appears to be an error during probing
for zfs, and I made some fixes related to probing for zfs.

-- Ian

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

Re: Question about 'gptzfsboot'

[Toomas Soome]

> On 29 Apr 2019, at 21:47, Thomas Laus  wrote:
> 
> On 2019-04-29 14:27, Thomas Laus wrote:
>> It was more than a broken console.  All of the other 2 computers that I
>> upgraded to r346885 were essentially 'dead'.  I could not even remotely
>> login to them via ssh.  All of them required a hard power button reset
>> to get into single user mode to let me comment out the rc.conf line that
>> loads the DRM driver.  The computer could successfully boot without DRM
>> activation but would go to a black console screen again with 'startx'.
>> This also required a hard power button shutdown.  I rolled back to
>> r346544 and everything worked again like before.
>> 
>> My disastrous update to r346885 included installing a new gptzfsboot and
>> pmbr in the drive boot record.  I did not try booting an older kernel
>> using the new gptzfsboot.  I was concerned about the lack of ssh login
>> when the computers lost their console, so I just rolled back my system
>> to the last snapshot made a week ago.
>> 
> Ian:
> 
> I re-activated the r346885 BEADM snapshot and booted from my
> 'kernel.old' from r346544 and everything came up OK including 'X'.
> 
> I don't know what that means.  It might be that I have a DRM issue
> instead of a gptzfsboot problem?  Everything except for the kernel is
> now running CURRENT r346885.  I am not using the updated
> drm-current-kmod because I am using the r346544 kernel.old.
> 

It means you have different issues - one is about gptzfsboot causing boot 
problems and apparently it got fixed when you did update the bootcode (the boot 
partition is global). But also you got bitten by DRM update, and since you had 
old BE around, you were able to load old kernel.

Now the question is, is that gptzfsboot issue really fixed or is it just the 
“warm boot” fix you were seeing earlier too.

rgds,
toomas


> Tom
> 
> 
> -- 
> Public Keys:
> PGP KeyID = 0x5F22FDC1
> GnuPG KeyID = 0x620836CF
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

Re: Question about 'gptzfsboot'

[Thomas Laus]

On 2019-04-29 14:27, Thomas Laus wrote:
> It was more than a broken console.  All of the other 2 computers that I
> upgraded to r346885 were essentially 'dead'.  I could not even remotely
> login to them via ssh.  All of them required a hard power button reset
> to get into single user mode to let me comment out the rc.conf line that
> loads the DRM driver.  The computer could successfully boot without DRM
> activation but would go to a black console screen again with 'startx'.
> This also required a hard power button shutdown.  I rolled back to
> r346544 and everything worked again like before.
> 
> My disastrous update to r346885 included installing a new gptzfsboot and
> pmbr in the drive boot record.  I did not try booting an older kernel
> using the new gptzfsboot.  I was concerned about the lack of ssh login
> when the computers lost their console, so I just rolled back my system
> to the last snapshot made a week ago.
>
Ian:

I re-activated the r346885 BEADM snapshot and booted from my
'kernel.old' from r346544 and everything came up OK including 'X'.

I don't know what that means.  It might be that I have a DRM issue
instead of a gptzfsboot problem?  Everything except for the kernel is
now running CURRENT r346885.  I am not using the updated
drm-current-kmod because I am using the r346544 kernel.old.

Tom


-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about 'gptzfsboot'

[Thomas Laus]

On 2019-04-29 11:14, Ian Lepore wrote:
> 
> I'm fighting my own video driver troubles (seems like a lot of that
> going around lately); on an upgrade of a machine from 11-stable to 12-
> stable I lost my console.
> 
> But, a broken kernel and/or userland shouldn't affect your ability to
> use the new boot components.  That is, you can use gptzfsboot and
> loader that contain my fixes, and use them to load an older kernel that
> has working video drivers.
>
Ian:

It was more than a broken console.  All of the other 2 computers that I
upgraded to r346885 were essentially 'dead'.  I could not even remotely
login to them via ssh.  All of them required a hard power button reset
to get into single user mode to let me comment out the rc.conf line that
loads the DRM driver.  The computer could successfully boot without DRM
activation but would go to a black console screen again with 'startx'.
This also required a hard power button shutdown.  I rolled back to
r346544 and everything worked again like before.

My disastrous update to r346885 included installing a new gptzfsboot and
pmbr in the drive boot record.  I did not try booting an older kernel
using the new gptzfsboot.  I was concerned about the lack of ssh login
when the computers lost their console, so I just rolled back my system
to the last snapshot made a week ago.

Tom



-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about 'gptzfsboot'

[Thomas Laus]

On 2019-04-29 10:33, Thomas Laus wrote:
> Updating to r346885 turned out to be a disaster!  There were changes to
> DRM between FreeBSD 13.0-CURRENT r346544 and r346885.  The desktop that
> I use for a build machine because it is much faster than any of my other
> PC's installed kernel and world without any problems including starting
> 'X'.  I had to update the drm-current-kmod port on my build PC.  Nothing
> was in /usr/src/UPDATING or /usr/ports/UPDATING about the need to do so.
> DRM on my build computer did not start until the update and then worked
> as expected.
> 
> I did the same on my Dell laptop and it crashed on the first boot right
> after loading DRM-kmod.  I removed the line in rc.conf that activates
> the kernel module and my laptop booted into multiuser.  When I started
> 'X' it crashed just like before.  The screen was black and I could not
> login remotely via SSH.  Nothing in any system log.  The Xorg log shows
> this and stops:
>
Ian:

I updated my other desktop PC's (Intel Atom D510 and Dell AMD Sempron)
and received the same black screen, not responsive, no log events just
like my laptop with CURRENT r346885 and the DRM kmod update from ports.
 The only computer that had success was my Intel i5 Skylake.  I did not
try updating my other laptop since r346885 had issues on three
computers.  Recovery also required a BEADM rollback to the last
successful snapshot.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about 'gptzfsboot'

[Ian Lepore]

On Mon, 2019-04-29 at 10:33 -0400, Thomas Laus wrote:
> > On 2019-04-28 22:27, Ian Lepore wrote:
> > > 
> > > If you're using gptzfsboot, I guess you're using zfs?  I just
> > > fixed a
> > > problem with probing disks for zfs volumes a few days ago
> > > (r346675). 
> > > There is even some small chance it fixes this problem, because
> > > one of
> > > the things I noticed was that in one of the disk structures in
> > > loader,
> > > the "slice offset" value was sometimes a bit random-looking, like
> > > it
> > > was being initialized with whatever garbage was laying around in
> > > memory.  It actually makes some sense that the "garbage" might be
> > > different between a firstboot after power-on and a reboot.
> > > 
> > > So all in all, it wouldn't hurt to update both gptzfsboot and
> > > loader
> > > (gpart bootcode -b and -p) to see if there's a fix lurking in my
> > > zfs
> > > probe changes.
> > > 
> > 
> > I'll build and update my laptop OS this morning and report back to
> > this
> > thread if I have any additional issues.
> > 
> 
> Ian:
> 
> Updating to r346885 turned out to be a disaster!  There were changes
> to
> DRM between FreeBSD 13.0-CURRENT r346544 and r346885.  The desktop
> that
> I use for a build machine because it is much faster than any of my
> other
> PC's installed kernel and world without any problems including
> starting
> 'X'.  I had to update the drm-current-kmod port on my build
> PC.  Nothing
> was in /usr/src/UPDATING or /usr/ports/UPDATING about the need to do
> so.
>  DRM on my build computer did not start until the update and then
> worked
> as expected.
> 
> I did the same on my Dell laptop and it crashed on the first boot
> right
> after loading DRM-kmod.  I removed the line in rc.conf that activates
> the kernel module and my laptop booted into multiuser.  When I
> started
> 'X' it crashed just like before.  The screen was black and I could
> not
> login remotely via SSH.  Nothing in any system log.  The Xorg log
> shows
> this and stops:
> 
>  40.979]compiled for 1.18.4, module version = 2.4.0
> [40.979]Module class: X.Org Video Driver
> [40.979]ABI class: X.Org Video Driver, version 20.0
> [40.979] (II) intel: Driver for Intel(R) Integrated Graphics
> Chipsets:
> i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM,
> 865G,
> 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
> Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33,
> Q35,
> Q33,
> GM45, 4 Series, G45/G43, Q45/Q43, G41, B43
> [40.981] (II) intel: Driver for Intel(R) HD Graphics
> [40.981] (II) intel: Driver for Intel(R) Iris(TM) Graphics
> [40.981] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics
> [40.981] (II) modesetting: Driver for Modesetting Kernel Drivers:
> kms
> [40.981] (II) scfb: driver for wsdisplay framebuffer: scfb
> [40.981] (II) VESA: driver for VESA chipsets: vesa
> [40.981] (--) Using syscons driver with X support (version 2.0)
> [40.981] (--) using VT number 9
> 
> I had to recover my system using beadm to rollback to the last
> CURRENT
> snapshot from a week ago.
> 
> Tom
> 
> 

I'm fighting my own video driver troubles (seems like a lot of that
going around lately); on an upgrade of a machine from 11-stable to 12-
stable I lost my console.

But, a broken kernel and/or userland shouldn't affect your ability to
use the new boot components.  That is, you can use gptzfsboot and
loader that contain my fixes, and use them to load an older kernel that
has working video drivers.

-- Ian


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

Re: Question about 'gptzfsboot'

[Thomas Laus]

> On 2019-04-28 22:27, Ian Lepore wrote:
>>
>> If you're using gptzfsboot, I guess you're using zfs?  I just fixed a
>> problem with probing disks for zfs volumes a few days ago (r346675). 
>> There is even some small chance it fixes this problem, because one of
>> the things I noticed was that in one of the disk structures in loader,
>> the "slice offset" value was sometimes a bit random-looking, like it
>> was being initialized with whatever garbage was laying around in
>> memory.  It actually makes some sense that the "garbage" might be
>> different between a firstboot after power-on and a reboot.
>>
>> So all in all, it wouldn't hurt to update both gptzfsboot and loader
>> (gpart bootcode -b and -p) to see if there's a fix lurking in my zfs
>> probe changes.
>>
> I'll build and update my laptop OS this morning and report back to this
> thread if I have any additional issues.
>
Ian:

Updating to r346885 turned out to be a disaster!  There were changes to
DRM between FreeBSD 13.0-CURRENT r346544 and r346885.  The desktop that
I use for a build machine because it is much faster than any of my other
PC's installed kernel and world without any problems including starting
'X'.  I had to update the drm-current-kmod port on my build PC.  Nothing
was in /usr/src/UPDATING or /usr/ports/UPDATING about the need to do so.
 DRM on my build computer did not start until the update and then worked
as expected.

I did the same on my Dell laptop and it crashed on the first boot right
after loading DRM-kmod.  I removed the line in rc.conf that activates
the kernel module and my laptop booted into multiuser.  When I started
'X' it crashed just like before.  The screen was black and I could not
login remotely via SSH.  Nothing in any system log.  The Xorg log shows
this and stops:

 40.979]compiled for 1.18.4, module version = 2.4.0
[40.979]Module class: X.Org Video Driver
[40.979]ABI class: X.Org Video Driver, version 20.0
[40.979] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets:
i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G,
915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35,
Q33,
GM45, 4 Series, G45/G43, Q45/Q43, G41, B43
[40.981] (II) intel: Driver for Intel(R) HD Graphics
[40.981] (II) intel: Driver for Intel(R) Iris(TM) Graphics
[40.981] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics
[40.981] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[40.981] (II) scfb: driver for wsdisplay framebuffer: scfb
[40.981] (II) VESA: driver for VESA chipsets: vesa
[40.981] (--) Using syscons driver with X support (version 2.0)
[40.981] (--) using VT number 9

I had to recover my system using beadm to rollback to the last CURRENT
snapshot from a week ago.

Tom


-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about 'gptzfsboot'

[Thomas Laus]

On 2019-04-28 22:27, Ian Lepore wrote:
> 
> If you're using gptzfsboot, I guess you're using zfs?  I just fixed a
> problem with probing disks for zfs volumes a few days ago (r346675). 
> There is even some small chance it fixes this problem, because one of
> the things I noticed was that in one of the disk structures in loader,
> the "slice offset" value was sometimes a bit random-looking, like it
> was being initialized with whatever garbage was laying around in
> memory.  It actually makes some sense that the "garbage" might be
> different between a firstboot after power-on and a reboot.
> 
> So all in all, it wouldn't hurt to update both gptzfsboot and loader
> (gpart bootcode -b and -p) to see if there's a fix lurking in my zfs
> probe changes.
>
I'll build and update my laptop OS this morning and report back to this
thread if I have any additional issues.

Thanks

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about 'gptzfsboot'

[Ian Lepore]

On Sun, 2019-04-28 at 19:29 -0400, Thomas Laus wrote:
> On 2019-04-28 08:07, Ronald Klop wrote:
> > 
> > Is this the same as this?
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=144234
> > 
> 
> The messages are similar.  The boot process will normally proceed on
> the
> second or third attempt.  On some days, I don't see this message
> appear
> and my laptops boot normally.  I don't think that this problem is
> hardware related.  One laptop is a Compaq Pavilion with an AMD Turion
> CPU and the other is a Dell Inspiron with an Intel Core2 Duo
> CPU.  One
> hard drive is mechanical and the other is a SSD.  I have swapped hard
> drives between the two laptops and the issue still shows up on
> occasion
> with each PC.  I have never seen this issue on any of my desktop
> computers.  Everything is running FreeBSD 13.0-CURRENT r346544
> GENERIC-NODEBUG at the moment.  The thread in the bug report also
> shows
> a smaller LBA number, mine is LBA 18446744072709551608 and much
> further
> in geometry than most of the reported issues.  I have seen this issue
> since FreeBSD 12 was CURRENT.  Since the boot process will work on a
> second or third boot attempt, it is not a show stopper for me.
> 
> Tom
> 

If you're using gptzfsboot, I guess you're using zfs?  I just fixed a
problem with probing disks for zfs volumes a few days ago (r346675). 
There is even some small chance it fixes this problem, because one of
the things I noticed was that in one of the disk structures in loader,
the "slice offset" value was sometimes a bit random-looking, like it
was being initialized with whatever garbage was laying around in
memory.  It actually makes some sense that the "garbage" might be
different between a firstboot after power-on and a reboot.

So all in all, it wouldn't hurt to update both gptzfsboot and loader
(gpart bootcode -b and -p) to see if there's a fix lurking in my zfs
probe changes.

-- Ian

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

Re: Question about 'gptzfsboot'

[Warner Losh]

On Sun, Apr 28, 2019 at 5:30 PM Thomas Laus  wrote:

> On 2019-04-28 08:07, Ronald Klop wrote:
> >
> > Is this the same as this?
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=144234
> >
> The messages are similar.  The boot process will normally proceed on the
> second or third attempt.  On some days, I don't see this message appear
> and my laptops boot normally.  I don't think that this problem is
> hardware related.  One laptop is a Compaq Pavilion with an AMD Turion
> CPU and the other is a Dell Inspiron with an Intel Core2 Duo CPU.  One
> hard drive is mechanical and the other is a SSD.  I have swapped hard
> drives between the two laptops and the issue still shows up on occasion
> with each PC.  I have never seen this issue on any of my desktop
> computers.  Everything is running FreeBSD 13.0-CURRENT r346544
> GENERIC-NODEBUG at the moment.  The thread in the bug report also shows
> a smaller LBA number, mine is LBA 18446744072709551608 and much further
> in geometry than most of the reported issues.  I have seen this issue
> since FreeBSD 12 was CURRENT.  Since the boot process will work on a
> second or third boot attempt, it is not a show stopper for me.


Ever boot with thumb drives plugged in? Does the DVD player have a disk in
it?

Warner

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

Re: Question about 'gptzfsboot'

[Thomas Laus]

On 2019-04-28 08:07, Ronald Klop wrote:
> 
> Is this the same as this?
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=144234
>
The messages are similar.  The boot process will normally proceed on the
second or third attempt.  On some days, I don't see this message appear
and my laptops boot normally.  I don't think that this problem is
hardware related.  One laptop is a Compaq Pavilion with an AMD Turion
CPU and the other is a Dell Inspiron with an Intel Core2 Duo CPU.  One
hard drive is mechanical and the other is a SSD.  I have swapped hard
drives between the two laptops and the issue still shows up on occasion
with each PC.  I have never seen this issue on any of my desktop
computers.  Everything is running FreeBSD 13.0-CURRENT r346544
GENERIC-NODEBUG at the moment.  The thread in the bug report also shows
a smaller LBA number, mine is LBA 18446744072709551608 and much further
in geometry than most of the reported issues.  I have seen this issue
since FreeBSD 12 was CURRENT.  Since the boot process will work on a
second or third boot attempt, it is not a show stopper for me.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about 'gptzfsboot'

[Ronald Klop]

On Fri, 26 Apr 2019 13:31:02 +0200, Thomas Laus  wrote:


List:

I have been having gptzfsboot issues with my two laptops since 12.0 was
still CURRENT.  I receive 'error 1' on the first boot most days.

gptzfsboot: error 1 LBA 18446744072709551608
gptzfsboot: error 1 LBA 1
gptzfsboot: No ZFS pools located, can't boot


Is this the same as this?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=144234

Regards,

Ronald.



Most of the time the boot process is successful on my next attempt.
This happens on two different laptops (different manufacturer).
Different hard drives (one mechanical, the other SSD).  Both laptops are
running 13.0-CURRENT FreeBSD 13.0-CURRENT r346544 GENERIC-NODEBUG.  All
of my desktop computers are running the same version of FreeBSD and
never exhibit this issue.  Is there something unique to a laptop reading
the boot record and looking for a GELI encrypted partition that a
desktop does not?

Tom

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

Re: Question about 'gptzfsboot'

[Thomas Laus]

Toomas Soome [tso...@me.com] wrote:
> 
> > I always update the bootcode with gpart each time when updating my system.
> > 
> 
> Oh right, this from gptzfsboot… ok, I guess I should do something
> I have been planning all along… Do you need some sort of quick workaround?
>
No quick workaround is required, take your time.  This is minor issue
for me because my laptops mostly boot on the next attempt.

Thanks for the quick response.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about 'gptzfsboot'

[Toomas Soome]

> On 26 Apr 2019, at 16:20, Thomas Laus  wrote:
> 
> Toomas Soome [tso...@me.com] wrote:
>> 
>> The key is about LBA in first message. Make sure you have latest
>> boot code installed with gpart.
>> 
> I always update the bootcode with gpart each time when updating my system.
> 

Oh right, this from gptzfsboot… ok, I guess I should do something I have been 
planning all along… Do you need some sort of quick workaround?

rgds,
toomas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about 'gptzfsboot'

[Thomas Laus]

Toomas Soome [tso...@me.com] wrote:
> 
> The key is about LBA in first message. Make sure you have latest
> boot code installed with gpart.
> 
I always update the bootcode with gpart each time when updating my system.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about 'gptzfsboot'

[Toomas Soome]

> On 26 Apr 2019, at 14:31, Thomas Laus  wrote:
> 
> List:
> 
> I have been having gptzfsboot issues with my two laptops since 12.0 was
> still CURRENT.  I receive 'error 1' on the first boot most days.
> 
> gptzfsboot: error 1 LBA 18446744072709551608
> gptzfsboot: error 1 LBA 1
> gptzfsboot: No ZFS pools located, can't boot
> 
> Most of the time the boot process is successful on my next attempt.
> This happens on two different laptops (different manufacturer).
> Different hard drives (one mechanical, the other SSD).  Both laptops are
> running 13.0-CURRENT FreeBSD 13.0-CURRENT r346544 GENERIC-NODEBUG.  All
> of my desktop computers are running the same version of FreeBSD and
> never exhibit this issue.  Is there something unique to a laptop reading
> the boot record and looking for a GELI encrypted partition that a
> desktop does not?
> 


The key is about LBA in first message. Make sure you have latest boot code 
installed with gpart.

rgds,
toomas

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

Re: Question mark on Lua menu box

[Renato Botelho]

On 02/03/18 12:55, Kyle Evans wrote:
> On Fri, Mar 2, 2018 at 9:52 AM, Renato Botelho  wrote:
>> On 02/03/18 12:31, Kyle Evans wrote:
>>> On Fri, Mar 2, 2018 at 6:06 AM, Renato Botelho  wrote:
 Kyle,

 I've moved to Lua loader to help testing and it worked fine. The only
 odd thing I noted is the menu box with odd chars as you can see at [1].

 My laptop is running a recent current (r330275) with ZFS and UEFI.

 [1] https://imgur.com/a/kIQ0O
 --
 Renato Botelho

>>>
>>> Hi,
>>>
>>> Thanks for testing! =) Can you give it a shot with EFI boot after
>>> r330281 (just committed), please?
>>>
>>> I think our working theory is that we were printing newlines along
>>> with our box-drawing characters, and that could be problematic. The
>>> new version handles all of that a little better and respects
>>> loader_menu_frame to boot.
>>
>> Hi,
>>
>> Unfortunately it didn't change anything.
>>
> 
> Aw =(. Can you take a picture of what Forth loader looks like for you
> with the default frame style on an EFI boot? I'm wondering if it's not
> doing something sneaky that I can't determine from the things I've
> looked at.

Sure, here it is:

https://imgur.com/a/fmO8w

-- 
Renato Botelho
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question mark on Lua menu box

[Kyle Evans]

On Fri, Mar 2, 2018 at 9:52 AM, Renato Botelho  wrote:
> On 02/03/18 12:31, Kyle Evans wrote:
>> On Fri, Mar 2, 2018 at 6:06 AM, Renato Botelho  wrote:
>>> Kyle,
>>>
>>> I've moved to Lua loader to help testing and it worked fine. The only
>>> odd thing I noted is the menu box with odd chars as you can see at [1].
>>>
>>> My laptop is running a recent current (r330275) with ZFS and UEFI.
>>>
>>> [1] https://imgur.com/a/kIQ0O
>>> --
>>> Renato Botelho
>>>
>>
>> Hi,
>>
>> Thanks for testing! =) Can you give it a shot with EFI boot after
>> r330281 (just committed), please?
>>
>> I think our working theory is that we were printing newlines along
>> with our box-drawing characters, and that could be problematic. The
>> new version handles all of that a little better and respects
>> loader_menu_frame to boot.
>
> Hi,
>
> Unfortunately it didn't change anything.
>

Aw =(. Can you take a picture of what Forth loader looks like for you
with the default frame style on an EFI boot? I'm wondering if it's not
doing something sneaky that I can't determine from the things I've
looked at.

Thanks,

Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question mark on Lua menu box

[Renato Botelho]

On 02/03/18 12:31, Kyle Evans wrote:
> On Fri, Mar 2, 2018 at 6:06 AM, Renato Botelho  wrote:
>> Kyle,
>>
>> I've moved to Lua loader to help testing and it worked fine. The only
>> odd thing I noted is the menu box with odd chars as you can see at [1].
>>
>> My laptop is running a recent current (r330275) with ZFS and UEFI.
>>
>> [1] https://imgur.com/a/kIQ0O
>> --
>> Renato Botelho
>>
> 
> Hi,
> 
> Thanks for testing! =) Can you give it a shot with EFI boot after
> r330281 (just committed), please?
> 
> I think our working theory is that we were printing newlines along
> with our box-drawing characters, and that could be problematic. The
> new version handles all of that a little better and respects
> loader_menu_frame to boot.

Hi,

Unfortunately it didn't change anything.

-- 
Renato Botelho
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question mark on Lua menu box

[Kyle Evans]

On Fri, Mar 2, 2018 at 6:06 AM, Renato Botelho  wrote:
> Kyle,
>
> I've moved to Lua loader to help testing and it worked fine. The only
> odd thing I noted is the menu box with odd chars as you can see at [1].
>
> My laptop is running a recent current (r330275) with ZFS and UEFI.
>
> [1] https://imgur.com/a/kIQ0O
> --
> Renato Botelho
>

Hi,

Thanks for testing! =) Can you give it a shot with EFI boot after
r330281 (just committed), please?

I think our working theory is that we were printing newlines along
with our box-drawing characters, and that could be problematic. The
new version handles all of that a little better and respects
loader_menu_frame to boot.

Thanks,

Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question mark on Lua menu box

[Ed Maste]

On 2 March 2018 at 07:06, Renato Botelho  wrote:
> Kyle,
>
> I've moved to Lua loader to help testing and it worked fine. The only
> odd thing I noted is the menu box with odd chars as you can see at [1].

Hi Renato, thanks for testing! Are you booting via BIOS or UEFI?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about wmb() and rmb() and task switching

[Konstantin Belousov]

On Fri, Sep 23, 2016 at 01:46:15PM +0200, Hans Petter Selasky wrote:
> Hi,
> 
> Does use of wmb() and rmb() for amd64 as defined in 
> sys/amd64/include/atomic.h required use of critical_enter()/critical_exit().
> 
> I was looking at the code in sys/amd64/amd64/cpu_switch.S which switches 
> between threads and I don't see any "sfence" instructions in there.
> 
> Given the following piece of dummy code:
> 
> var_a = 1;
> var_b = 2;
> wmb();
> 
> If there is a task switch between writing var_a and var_b so that the 
> thread in question continues executing on another core, can it happen 
> that the write to var_a is not flushed when wmb() is executed?
> 
> var_a = 1;
> 
> var_b = 2;
> wmb();

cpu_switch() guarantees that the context switch behaves as a full
barrier. In other words, all side-effects which are before context
switch in the program order, become globally visible after it (if
address spaces are switched), context switch behaves as the strongest
barrier among all provided by the hardware.

For amd64, there are more than one serialization instructions executed
during the switch, including the access to cr3 and thread unlock for old
thread.  If the context switch is involuntary, then the interrupt itself
also provides serialization point.

Note that FreeBSD uses C11 memory model of load acquire/store release,
not the linux-like rmb/wmb. atomic acq/rel ops are strongly preferred
over the *mb(), which mostly exists as the initial driver porting aid.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about cam 4K quirks

[Steven Hartland]

On 11/04/2016 15:24, Tomoaki AOKI wrote:

Thanks for your answer!

On Sun, 10 Apr 2016 16:15:56 +0100
Steven Hartland  wrote:



On 10/04/2016 15:35, Tomoaki AOKI wrote:

On Sun, 10 Apr 2016 06:59:04 -0600
Alan Somers  wrote:


On Sun, Apr 10, 2016 at 12:56 AM, Tomoaki AOKI 
wrote:


Hi. Maybe freebsd-hardware list would be the right place, but it's not
so active. :-(

Is 4K quirks needed for every HDDs/SSDs having physical sector size
4096?

If so, I would be able to provide patch for Crucial M550 and MX200.
(Possibly covers other models [BX200 etc.] by abstraction.)

M550(1TB):  device model  Crucial CT1024M550SSD1
firmware revision MU01
MX200(1TB): device model  Crucial CT1024MX200SSD1
firmware revision MU03
  -> Abstracted with "Crucial CT*SSD*" or "Crucial CT*", as the part
 "1024" should vary with its capacity and can be 3 to 4 digits
 for now. I tried the former and confirmed "quirks=0x1<4K>"
 appears, which doesn't appear without adding the entry.


If not, is it sufficient if `camcontrol identify ` states
"physical 4096" on "sector size" line for everything in kernel and
related components (i.e., zfs-related ones)?


Regards.

You only need quirk entries if the device fails to identify its physical
size correctly.  If "camcontrol identify" states "physical 4096", then
you're probably ok, but it's not the best place to ask.  "camcontrol
identify" asks the device directly, whereas "diskinfo -v" asks the kernel.
If "diskinfo -v" says "4096 stripesize" then you're definitely ok.

-Alan

Thanks for clarification.

Tried "diskinfo -v" as you noted (of course running the kernel without
adding quirks entry) and confirmed it saying "4096 # stripesize".
So it's already OK with current ata_da.c and scsi_da.c (no quirks is
needed).

OTOH, trying with Samsung 850 evo (the last one I have for now,
having quirks entry in current source), "diskinfo -v" says "4096
# stripesize" while "camcontrol identify" says "physical 512".
This should be why quirks entries are needed (and implemented) for it.

Correct, manufactures took the cop out route and return 512 for both
logical and physical sizes to avoid issues with bad OS support.
SSD's a particularly lazy in this regard.

I think stripesize should be primarily for RAID configuration, but
after 4k physical sectored drives  (so called AFT drives) appears,
applied to even for single drive configuration, too. Right?

stripesize simply gives a hit as to performance when accessing the device.

So now FreeBSD's ZFS defaults ashift 12, if I remember correctly, to
align datasets with 4k.
ZFS calculates the most suitable given the reports physical and logical 
sector sizes, technically the default is ashift 9 unless altered by 
setting vfs.zfs.min_auto_ashift.

And UFS has minimum blocksize of 4k (defaults
8k). And more, now gpart can align partitions as root specifies.


If so, as writing blocks smaller than stripesize (except for the last
block of a file) is nonsense for RAID configuration, all write access
to HDDs/SSDs are constrained to use stripesize for minimum block size,
right?

Nope, sectorsize constrains that.

So possibly some filesystems can be mis-aligned even if the start point
is properly aligned.

  *Mis-aligned fragments should be allowed, though.


stripesize is only used as a way to help tune filesystem access patterns
e.g. in ZFS it is used to help determine the ashift value which in turn
determines the minimum allocatable block size. This helps optimise
performance while sacrificing storage space i.e. causing wastage.

Exactly. :-)
But there's large possibility of severe performance degradation caused
by mis-aligned blocks, especially in HDD, and the capacities of HDDs
became large, even in 2.5inch form factor. Defaulting block size to
physical sector size would be reasonable, if any option to downsize to
512 bytes is provided.

That would be a step back, correcting the offset would be the better fix.

  *If I remember correctly, block size of UFS is 4096 bytes at minimum,
   but supports 512 bytes fragments for small files (and to concentrate
   tail portions of large files). It would be in many cases reasonable
   trade-off, too.

I don't use UFS so couldn't comment.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about cam 4K quirks

[Tomoaki AOKI]

Thanks for your answer!

On Sun, 10 Apr 2016 16:15:56 +0100
Steven Hartland  wrote:

> 
> 
> On 10/04/2016 15:35, Tomoaki AOKI wrote:
> > On Sun, 10 Apr 2016 06:59:04 -0600
> > Alan Somers  wrote:
> >
> >> On Sun, Apr 10, 2016 at 12:56 AM, Tomoaki AOKI 
> >> wrote:
> >>
> >>> Hi. Maybe freebsd-hardware list would be the right place, but it's not
> >>> so active. :-(
> >>>
> >>> Is 4K quirks needed for every HDDs/SSDs having physical sector size
> >>> 4096?
> >>>
> >>> If so, I would be able to provide patch for Crucial M550 and MX200.
> >>> (Possibly covers other models [BX200 etc.] by abstraction.)
> >>>
> >>>M550(1TB):  device model  Crucial CT1024M550SSD1
> >>>firmware revision MU01
> >>>MX200(1TB): device model  Crucial CT1024MX200SSD1
> >>>firmware revision MU03
> >>>  -> Abstracted with "Crucial CT*SSD*" or "Crucial CT*", as the part
> >>> "1024" should vary with its capacity and can be 3 to 4 digits
> >>> for now. I tried the former and confirmed "quirks=0x1<4K>"
> >>> appears, which doesn't appear without adding the entry.
> >>>
> >>>
> >>> If not, is it sufficient if `camcontrol identify ` states
> >>> "physical 4096" on "sector size" line for everything in kernel and
> >>> related components (i.e., zfs-related ones)?
> >>>
> >>>
> >>> Regards.
> >>
> >> You only need quirk entries if the device fails to identify its physical
> >> size correctly.  If "camcontrol identify" states "physical 4096", then
> >> you're probably ok, but it's not the best place to ask.  "camcontrol
> >> identify" asks the device directly, whereas "diskinfo -v" asks the kernel.
> >> If "diskinfo -v" says "4096 stripesize" then you're definitely ok.
> >>
> >> -Alan
> > Thanks for clarification.
> >
> > Tried "diskinfo -v" as you noted (of course running the kernel without
> > adding quirks entry) and confirmed it saying "4096 # stripesize".
> > So it's already OK with current ata_da.c and scsi_da.c (no quirks is
> > needed).
> >
> > OTOH, trying with Samsung 850 evo (the last one I have for now,
> > having quirks entry in current source), "diskinfo -v" says "4096
> > # stripesize" while "camcontrol identify" says "physical 512".
> > This should be why quirks entries are needed (and implemented) for it.
> Correct, manufactures took the cop out route and return 512 for both 
> logical and physical sizes to avoid issues with bad OS support.
> SSD's a particularly lazy in this regard.
> > I think stripesize should be primarily for RAID configuration, but
> > after 4k physical sectored drives  (so called AFT drives) appears,
> > applied to even for single drive configuration, too. Right?
> stripesize simply gives a hit as to performance when accessing the device.

So now FreeBSD's ZFS defaults ashift 12, if I remember correctly, to
align datasets with 4k. And UFS has minimum blocksize of 4k (defaults
8k). And more, now gpart can align partitions as root specifies.

> > If so, as writing blocks smaller than stripesize (except for the last
> > block of a file) is nonsense for RAID configuration, all write access
> > to HDDs/SSDs are constrained to use stripesize for minimum block size,
> > right?
> Nope, sectorsize constrains that.

So possibly some filesystems can be mis-aligned even if the start point
is properly aligned.

 *Mis-aligned fragments should be allowed, though.

> 
> stripesize is only used as a way to help tune filesystem access patterns 
> e.g. in ZFS it is used to help determine the ashift value which in turn 
> determines the minimum allocatable block size. This helps optimise 
> performance while sacrificing storage space i.e. causing wastage.
> 
>  Regards
>  Steve

Exactly. :-)
But there's large possibility of severe performance degradation caused
by mis-aligned blocks, especially in HDD, and the capacities of HDDs
became large, even in 2.5inch form factor. Defaulting block size to
physical sector size would be reasonable, if any option to downsize to
512 bytes is provided.

 *If I remember correctly, block size of UFS is 4096 bytes at minimum,
  but supports 512 bytes fragments for small files (and to concentrate
  tail portions of large files). It would be in many cases reasonable
  trade-off, too.


Regards.

-- 
Tomoaki AOKIjunch...@dec.sakura.ne.jp
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about cam 4K quirks

[Steven Hartland]

On 10/04/2016 15:35, Tomoaki AOKI wrote:

On Sun, 10 Apr 2016 06:59:04 -0600
Alan Somers  wrote:


On Sun, Apr 10, 2016 at 12:56 AM, Tomoaki AOKI 
wrote:


Hi. Maybe freebsd-hardware list would be the right place, but it's not
so active. :-(

Is 4K quirks needed for every HDDs/SSDs having physical sector size
4096?

If so, I would be able to provide patch for Crucial M550 and MX200.
(Possibly covers other models [BX200 etc.] by abstraction.)

   M550(1TB):  device model  Crucial CT1024M550SSD1
   firmware revision MU01
   MX200(1TB): device model  Crucial CT1024MX200SSD1
   firmware revision MU03
 -> Abstracted with "Crucial CT*SSD*" or "Crucial CT*", as the part
"1024" should vary with its capacity and can be 3 to 4 digits
for now. I tried the former and confirmed "quirks=0x1<4K>"
appears, which doesn't appear without adding the entry.


If not, is it sufficient if `camcontrol identify ` states
"physical 4096" on "sector size" line for everything in kernel and
related components (i.e., zfs-related ones)?


Regards.


You only need quirk entries if the device fails to identify its physical
size correctly.  If "camcontrol identify" states "physical 4096", then
you're probably ok, but it's not the best place to ask.  "camcontrol
identify" asks the device directly, whereas "diskinfo -v" asks the kernel.
If "diskinfo -v" says "4096 stripesize" then you're definitely ok.

-Alan

Thanks for clarification.

Tried "diskinfo -v" as you noted (of course running the kernel without
adding quirks entry) and confirmed it saying "4096 # stripesize".
So it's already OK with current ata_da.c and scsi_da.c (no quirks is
needed).

OTOH, trying with Samsung 850 evo (the last one I have for now,
having quirks entry in current source), "diskinfo -v" says "4096
# stripesize" while "camcontrol identify" says "physical 512".
This should be why quirks entries are needed (and implemented) for it.
Correct, manufactures took the cop out route and return 512 for both 
logical and physical sizes to avoid issues with bad OS support.

SSD's a particularly lazy in this regard.

I think stripesize should be primarily for RAID configuration, but
after 4k physical sectored drives  (so called AFT drives) appears,
applied to even for single drive configuration, too. Right?

stripesize simply gives a hit as to performance when accessing the device.

If so, as writing blocks smaller than stripesize (except for the last
block of a file) is nonsense for RAID configuration, all write access
to HDDs/SSDs are constrained to use stripesize for minimum block size,
right?

Nope, sectorsize constrains that.

stripesize is only used as a way to help tune filesystem access patterns 
e.g. in ZFS it is used to help determine the ashift value which in turn 
determines the minimum allocatable block size. This helps optimise 
performance while sacrificing storage space i.e. causing wastage.


Regards
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about cam 4K quirks

[Tomoaki AOKI]

On Sun, 10 Apr 2016 06:59:04 -0600
Alan Somers  wrote:

> On Sun, Apr 10, 2016 at 12:56 AM, Tomoaki AOKI 
> wrote:
> 
> > Hi. Maybe freebsd-hardware list would be the right place, but it's not
> > so active. :-(
> >
> > Is 4K quirks needed for every HDDs/SSDs having physical sector size
> > 4096?
> >
> > If so, I would be able to provide patch for Crucial M550 and MX200.
> > (Possibly covers other models [BX200 etc.] by abstraction.)
> >
> >   M550(1TB):  device model  Crucial CT1024M550SSD1
> >   firmware revision MU01
> >   MX200(1TB): device model  Crucial CT1024MX200SSD1
> >   firmware revision MU03
> > -> Abstracted with "Crucial CT*SSD*" or "Crucial CT*", as the part
> >"1024" should vary with its capacity and can be 3 to 4 digits
> >for now. I tried the former and confirmed "quirks=0x1<4K>"
> >appears, which doesn't appear without adding the entry.
> >
> >
> > If not, is it sufficient if `camcontrol identify ` states
> > "physical 4096" on "sector size" line for everything in kernel and
> > related components (i.e., zfs-related ones)?
> >
> >
> > Regards.
> 
> 
> You only need quirk entries if the device fails to identify its physical
> size correctly.  If "camcontrol identify" states "physical 4096", then
> you're probably ok, but it's not the best place to ask.  "camcontrol
> identify" asks the device directly, whereas "diskinfo -v" asks the kernel.
> If "diskinfo -v" says "4096 stripesize" then you're definitely ok.
> 
> -Alan

Thanks for clarification.

Tried "diskinfo -v" as you noted (of course running the kernel without
adding quirks entry) and confirmed it saying "4096 # stripesize".
So it's already OK with current ata_da.c and scsi_da.c (no quirks is
needed).

OTOH, trying with Samsung 850 evo (the last one I have for now,
having quirks entry in current source), "diskinfo -v" says "4096 
# stripesize" while "camcontrol identify" says "physical 512".
This should be why quirks entries are needed (and implemented) for it.

I think stripesize should be primarily for RAID configuration, but
after 4k physical sectored drives  (so called AFT drives) appears,
applied to even for single drive configuration, too. Right?

If so, as writing blocks smaller than stripesize (except for the last
block of a file) is nonsense for RAID configuration, all write access
to HDDs/SSDs are constrained to use stripesize for minimum block size,
right?


Regards.

-- 
Tomoaki AOKIjunch...@dec.sakura.ne.jp
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about cam 4K quirks

[Alan Somers]

On Sun, Apr 10, 2016 at 12:56 AM, Tomoaki AOKI 
wrote:

> Hi. Maybe freebsd-hardware list would be the right place, but it's not
> so active. :-(
>
> Is 4K quirks needed for every HDDs/SSDs having physical sector size
> 4096?
>
> If so, I would be able to provide patch for Crucial M550 and MX200.
> (Possibly covers other models [BX200 etc.] by abstraction.)
>
>   M550(1TB):  device model  Crucial CT1024M550SSD1
>   firmware revision MU01
>   MX200(1TB): device model  Crucial CT1024MX200SSD1
>   firmware revision MU03
> -> Abstracted with "Crucial CT*SSD*" or "Crucial CT*", as the part
>"1024" should vary with its capacity and can be 3 to 4 digits
>for now. I tried the former and confirmed "quirks=0x1<4K>"
>appears, which doesn't appear without adding the entry.
>
>
> If not, is it sufficient if `camcontrol identify ` states
> "physical 4096" on "sector size" line for everything in kernel and
> related components (i.e., zfs-related ones)?
>
>
> Regards.


You only need quirk entries if the device fails to identify its physical
size correctly.  If "camcontrol identify" states "physical 4096", then
you're probably ok, but it's not the best place to ask.  "camcontrol
identify" asks the device directly, whereas "diskinfo -v" asks the kernel.
If "diskinfo -v" says "4096 stripesize" then you're definitely ok.

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

Re: question on support processor Intel Atom Z3735F

[Warren Block]

On Fri, 25 Mar 2016, Lundberg, Johannes wrote:


One problem is that most of these devices have only 32 bit UEFI which
FreeBSD does not support (except Intel Compute Stick which has 64 bit UEFI).


The MinnowBoard has both 32-bit and 64-bit UEFI.  My Turbot came with 
64-bit UEFI, and the FreeBSD amd64 UEFI install image works fine with 
it.  This is an Atom E3826 board.



I use special built Grub to boot a 64 bit Arch Linux on this chip, maybe
same approach could be used to boot a 64 bit FreeBSD. However, you probably
won't be able to use the internal eMMC (if your device got it) since the
controller can not initiate mmc memory correctly. Work in progress here
though by me and Ilya.

On a side note,
it would though be nice to have 32 bit UEFI support on FreeBSD because that
would include support for Intel IoT boards like Galileo etc which are all
32 bit. Might be a lot of work though..


If any existing 32-bit Linux UEFI loader could be made to work with 
FreeBSD (possibly chainloading?), that would be better than nothing.  I 
would like to have the opposite method also, having a 64-bit UEFI boot a 
32-bit FreeBSD.  (Why?  So my run-on-anything 32-bit FreeBSD image could 
still work on any UEFI system.)

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

Re: question on support processor Intel Atom Z3735F

[Lundberg, Johannes]

One problem is that most of these devices have only 32 bit UEFI which
FreeBSD does not support (except Intel Compute Stick which has 64 bit UEFI).
I use special built Grub to boot a 64 bit Arch Linux on this chip, maybe
same approach could be used to boot a 64 bit FreeBSD. However, you probably
won't be able to use the internal eMMC (if your device got it) since the
controller can not initiate mmc memory correctly. Work in progress here
though by me and Ilya.

On a side note,
it would though be nice to have 32 bit UEFI support on FreeBSD because that
would include support for Intel IoT boards like Galileo etc which are all
32 bit. Might be a lot of work though..


--
Name: Johannes Lundberg
Position: Mirama project leader
Phone:+1-408-636-2161
Skype:brilliantjohannes
Online:   LinkedIn  Facebook
 Reddit
 Twitter
 GitHub 
GitLab 
Company:  Mirama  Brilliantservice US
 Brilliantservice JP


On Fri, Mar 25, 2016 at 4:05 AM, Lars Engels  wrote:

> On Thu, Mar 24, 2016 at 10:06:05PM +0300, Владимир wrote:
> >  Hello, please tell me whether the FreeBSD operating system Intel Atom
> >  Z3735F? Which distribution I need to download?
>
>
> The CPU supports amd64 but AFAIK the Baytrail architecture only supports a
> 32-bit UEFI. So you need to create your own boot medium.
>

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: question on support processor Intel Atom Z3735F

[Lars Engels]

On Thu, Mar 24, 2016 at 10:06:05PM +0300, Владимир wrote:
>  Hello, please tell me whether the FreeBSD operating system Intel Atom
>  Z3735F? Which distribution I need to download?


The CPU supports amd64 but AFAIK the Baytrail architecture only supports a
32-bit UEFI. So you need to create your own boot medium.


pgpq8VrBBHKLV.pgp
Description: PGP signature

Re: question on support processor Intel Atom Z3735F

[peter garshtja]

Hi Vladimir,

I believe you need x86 arch.

Regards
On Mar 24, 2016 3:37 PM, "Владимир"  wrote:

>  Hello, please tell me whether the FreeBSD operating system Intel Atom
> Z3735F? Which distribution I need to download?
>
>
>
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: question on support processor Intel Atom Z3735F

[Lev Serebryakov]

On 24.03.2016 22:06, Владимир wrote:

> Intel Atom Z3735F
 Both x86 (32 bit) and amd64 (64 bit) will do. It depends on available
memory. If you have 4GB or more installed, try amd64.

-- 
// Lev Serebryakov



signature.asc
Description: OpenPGP digital signature

Re: question about pkgng

[Waitman Gobble]

On Sun, February 2, 2014 4:58 pm, Waitman Gobble wrote:
> Hi,
>
>
> I updated my laptop to:
>
>
> # uname -a
> FreeBSD akira.waitman.net 11.0-CURRENT FreeBSD 11.0-CURRENT #1: Sun Feb  2
>  21:45:49 PST 2014 r...@akira.waitman.net:/usr/obj/usr/src/sys/AKIRA
> amd64
>

Scratch this question, it turned out to be faster to just wipe out
/usr/local and start fresh, in this case.

Thanks

-- 
Waitman Gobble
San Jose California USA
+1.510-830-7975

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

Re: Question about socket timeouts

[Davide Italiano]

On Tue, Aug 27, 2013 at 7:10 AM, Vitja Makarov  wrote:
>> On Fri, Aug 23, 2013 at 7:04 AM, Vitja Makarov  
>> wrote:
>>> 2013/8/23 Davide Italiano :
>>>
>>> I think that for socket's timeouts it's ok to have a HZ-precision. It
>>> would be much more important to implement high-precision timeouts for
>>> select() and friends, if it's not done yet (sorry I'm running 9.1).
>>>
>>
>> JFYI, select()/usleep()/etc... are all fine grained right now in HEAD.
>>
>
> That's cool! Does that mean that FreeBSD 10 would be a tickless system?
>
> --
> vitja.

FreeBSD will have a tickless callout(9) subsystem. There are still
some kernel subsystems that depends on hardclock() even if the long
term goal is that of moving away from it (when/if possible). A notable
example is SCHED_ULE code which depends on hardclock() (sched_tick())
but it could be optimized to skip some calls even though CPU is
active.

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about socket timeouts

[Davide Italiano]

On Thu, Aug 29, 2013 at 6:03 PM, John Baldwin  wrote:
> On Monday, August 26, 2013 3:05:06 pm John Baldwin wrote:
>> On Monday, August 26, 2013 2:23:44 pm Davide Italiano wrote:
>> > Please consider the following patch:
>> > http://people.freebsd.org/~davide/review/socket_timeout.diff
>> > I've tested it and it works OK. I got a timeout which is ~= 25ms using
>> > the testcase provided by the user.
>> > The only doubt I have is about the range check, I've changed a bit
>> > because the 'integer' part of sbintime_t fits in 32-bits, but I'm not
>> > sure it's the best way of doing this.
>>
>> Nice!  Bruce actually wants me to adjust the range check a bit (which will
>> fit in well with your changes I think).  Please let me get that fix in
>> (so it can be part of the future MFC) and then you can commit this.  Thanks!
>>
>> Actually, I think you still need to patch the sogetopt() case to work 
>> correctly
>> (it is still doing a manual conversion from 'val' to a timeval assuming it is
>> in 'hz' units).
>
> I'm done with my range check changes, please move forward with your change
> (though make sure you fix the sogetsockopt() case please).
>
> --
> John Baldwin

For the archives, this should be fixed in r255138.

Thanks to both,

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about socket timeouts

[John Baldwin]

On Monday, August 26, 2013 3:05:06 pm John Baldwin wrote:
> On Monday, August 26, 2013 2:23:44 pm Davide Italiano wrote:
> > Please consider the following patch:
> > http://people.freebsd.org/~davide/review/socket_timeout.diff
> > I've tested it and it works OK. I got a timeout which is ~= 25ms using
> > the testcase provided by the user.
> > The only doubt I have is about the range check, I've changed a bit
> > because the 'integer' part of sbintime_t fits in 32-bits, but I'm not
> > sure it's the best way of doing this.
> 
> Nice!  Bruce actually wants me to adjust the range check a bit (which will
> fit in well with your changes I think).  Please let me get that fix in
> (so it can be part of the future MFC) and then you can commit this.  Thanks!
> 
> Actually, I think you still need to patch the sogetopt() case to work 
> correctly
> (it is still doing a manual conversion from 'val' to a timeval assuming it is
> in 'hz' units).

I'm done with my range check changes, please move forward with your change
(though make sure you fix the sogetsockopt() case please).

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

Re: Question about socket timeouts

[Vitja Makarov]

2013/8/26 Davide Italiano :
> Please consider the following patch:
> http://people.freebsd.org/~davide/review/socket_timeout.diff
> I've tested it and it works OK. I got a timeout which is ~= 25ms using
> the testcase provided by the user.
> The only doubt I have is about the range check, I've changed a bit
> because the 'integer' part of sbintime_t fits in 32-bits, but I'm not
> sure it's the best way of doing this.

Nice, that worked for me! I got ~26ms timeouts in average on my VM.

> On Fri, Aug 23, 2013 at 7:04 AM, Vitja Makarov  
> wrote:
>> 2013/8/23 Davide Italiano :
>>
>> I think that for socket's timeouts it's ok to have a HZ-precision. It
>> would be much more important to implement high-precision timeouts for
>> select() and friends, if it's not done yet (sorry I'm running 9.1).
>>
>
> JFYI, select()/usleep()/etc... are all fine grained right now in HEAD.
>

That's cool! Does that mean that FreeBSD 10 would be a tickless system?

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

Re: Question about socket timeouts

[John Baldwin]

On Monday, August 26, 2013 2:23:44 pm Davide Italiano wrote:
> On Fri, Aug 23, 2013 at 5:29 PM, John Baldwin  wrote:
> > On Friday, August 23, 2013 9:53:12 am Davide Italiano wrote:
> >> On Fri, Aug 23, 2013 at 3:45 PM, John Baldwin  wrote:
> >> > On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote:
> >> >> 2013/8/22 John Baldwin :
> >> >> > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote:
> >> >> >> 2013/8/21 John Baldwin :
> >> >> >> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote:
> >> >> >> >> On Mon, 19 Aug 2013, Adrian Chadd wrote:
> >> >> >> >>
> >> >> >> >> > Yes! Please file a PR!
> >> >> >> >>
> >> >> >> >> This sorta implies that both are acceptable (although,
> >> >> >> >> the Linux behavior seems more desirable).
> >> >> >> >>
> >> >> >> >>http://austingroupbugs.net/view.php?id=369
> >> >> >> >
> >> >> >> > No, that says "round up", so it does mean that the requested 
timeout
> >> >> >> > should be the minimum amount slept.  tvtohz() does this.  Really 
odd
> >> >> >> > that the socket code is using its own version of this rather than
> >> >> >> > tvtohz().
> >> >> >> >
> >> >> >> > Oh, I bet this just predates tvtohz().  Interesting that it keeps
> > getting
> >> >> >> > bug fixes in its history that simply using tvtohz() would have
> > solved.
> >> >> >> >
> >> >> >> > Try this:
> >> >> >> >
> >> >> >> > Index: uipc_socket.c
> >> >> >> > 
===
> >> >> >> > --- uipc_socket.c   (revision 254570)
> >> >> >> > +++ uipc_socket.c   (working copy)
> >> >> >> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct 
sockopt
> > *sopt)
> >> >> >> > if (error)
> >> >> >> > goto bad;
> >> >> >> >
> >> >> >> > -   /* assert(hz > 0); */
> >> >> >> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX 
/
> > hz ||
> >> >> >> > tv.tv_usec < 0 || tv.tv_usec >= 
100)
> > {
> >> >> >> > error = EDOM;
> >> >> >> > goto bad;
> >> >> >> > }
> >> >> >> > -   /* assert(tick > 0); */
> >> >> >> > -   /* assert(ULONG_MAX - INT_MAX >= 
100);
> > */
> >> >> >> > -   val = (u_long)(tv.tv_sec * hz) + 
tv.tv_usec
> > / tick;
> >> >> >> > -   if (val > INT_MAX) {
> >> >> >> > +   val = tvtohz(&tv);
> >> >> >> > +   if (val == INT_MAX) {
> >> >> >> > error = EDOM;
> >> >> >> > goto bad;
> >> >> >> > }
> >> >> >> > -   if (val == 0 && tv.tv_usec != 0)
> >> >> >> > -   val = 1;
> >> >> >> >
> >> >> >> > switch (sopt->sopt_name) {
> >> >> >> > case SO_SNDTIMEO:
> >> >> >> >
> >> >> >>
> >> >> >> That must help. But I want to see the issue solved in the next
> >> >> >> release. I can't apply patch to the production system. Btw in
> >> >> >> production environment we have kern.hz set to 1000 so it's not a
> >> >> >> problem there.
> >> >> >
> >> >> > Can you test this in some way in a test environment?
> >> >> >
> >> >>
> >> >> Ok, sorry for posting out of the list.
> >> >>
> >> >> Simple test program is attached. Without your patch timeout expires in
> >> >> about 20ms. With it it's ~40ms.
> >> >>
> >> >> 40 instead of 30 is beacuse of odd tick added by tvtohz().
> >> >
> >> > Ok, thanks.  tvtohz() will be good to MFC (and I will do that), but for
> >> > HEAD I think we can fix this to use a precise timeout.  I've cc'd 
davide@
> >> > so he can take a look at that.
> >> >
> >> > --
> >> > John Baldwin
> >>
> >> Hi,
> >> I think I can switch this code to new timeout KPI, but this will
> >> require the timeout field of 'struct sockbuf' to be changed from 'int'
> >> to 'sbintime_t' which breaks binary compatibility. Do you have any
> >> strong objections about this? If any, I would like this to happen ABI
> >> freeze, so it looks like this is the right moment.
> >
> > This should be fine to change now, it just can't be MFC'd (which we can't
> > do anyway).
> >
> > --
> > John Baldwin
> 
> Please consider the following patch:
> http://people.freebsd.org/~davide/review/socket_timeout.diff
> I've tested it and it works OK. I got a timeout which is ~= 25ms using
> the testcase provided by the user.
> The only doubt I have is about the range check, I've changed a bit
> because the 'integer' part of sbintime_t fits in 32-bits, but I'm not
> sure it's the best way of doing this.

Nice!  Bruce actually wants me to adjust the range check a bit (which will
fit in well with your changes I think).  Please let me get that fix in
(so it can be part of the future MFC) and then you can commit this.  Thanks!

Actually, I think yo

Re: Question about socket timeouts

[Davide Italiano]

On Fri, Aug 23, 2013 at 7:04 AM, Vitja Makarov  wrote:
> 2013/8/23 Davide Italiano :
>
> I think that for socket's timeouts it's ok to have a HZ-precision. It
> would be much more important to implement high-precision timeouts for
> select() and friends, if it's not done yet (sorry I'm running 9.1).
>

JFYI, select()/usleep()/etc... are all fine grained right now in HEAD.

>
> --
> vitja.



-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about socket timeouts

[Davide Italiano]

On Fri, Aug 23, 2013 at 5:29 PM, John Baldwin  wrote:
> On Friday, August 23, 2013 9:53:12 am Davide Italiano wrote:
>> On Fri, Aug 23, 2013 at 3:45 PM, John Baldwin  wrote:
>> > On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote:
>> >> 2013/8/22 John Baldwin :
>> >> > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote:
>> >> >> 2013/8/21 John Baldwin :
>> >> >> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote:
>> >> >> >> On Mon, 19 Aug 2013, Adrian Chadd wrote:
>> >> >> >>
>> >> >> >> > Yes! Please file a PR!
>> >> >> >>
>> >> >> >> This sorta implies that both are acceptable (although,
>> >> >> >> the Linux behavior seems more desirable).
>> >> >> >>
>> >> >> >>http://austingroupbugs.net/view.php?id=369
>> >> >> >
>> >> >> > No, that says "round up", so it does mean that the requested timeout
>> >> >> > should be the minimum amount slept.  tvtohz() does this.  Really odd
>> >> >> > that the socket code is using its own version of this rather than
>> >> >> > tvtohz().
>> >> >> >
>> >> >> > Oh, I bet this just predates tvtohz().  Interesting that it keeps
> getting
>> >> >> > bug fixes in its history that simply using tvtohz() would have
> solved.
>> >> >> >
>> >> >> > Try this:
>> >> >> >
>> >> >> > Index: uipc_socket.c
>> >> >> > ===
>> >> >> > --- uipc_socket.c   (revision 254570)
>> >> >> > +++ uipc_socket.c   (working copy)
>> >> >> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt
> *sopt)
>> >> >> > if (error)
>> >> >> > goto bad;
>> >> >> >
>> >> >> > -   /* assert(hz > 0); */
>> >> >> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX /
> hz ||
>> >> >> > tv.tv_usec < 0 || tv.tv_usec >= 100)
> {
>> >> >> > error = EDOM;
>> >> >> > goto bad;
>> >> >> > }
>> >> >> > -   /* assert(tick > 0); */
>> >> >> > -   /* assert(ULONG_MAX - INT_MAX >= 100);
> */
>> >> >> > -   val = (u_long)(tv.tv_sec * hz) + tv.tv_usec
> / tick;
>> >> >> > -   if (val > INT_MAX) {
>> >> >> > +   val = tvtohz(&tv);
>> >> >> > +   if (val == INT_MAX) {
>> >> >> > error = EDOM;
>> >> >> > goto bad;
>> >> >> > }
>> >> >> > -   if (val == 0 && tv.tv_usec != 0)
>> >> >> > -   val = 1;
>> >> >> >
>> >> >> > switch (sopt->sopt_name) {
>> >> >> > case SO_SNDTIMEO:
>> >> >> >
>> >> >>
>> >> >> That must help. But I want to see the issue solved in the next
>> >> >> release. I can't apply patch to the production system. Btw in
>> >> >> production environment we have kern.hz set to 1000 so it's not a
>> >> >> problem there.
>> >> >
>> >> > Can you test this in some way in a test environment?
>> >> >
>> >>
>> >> Ok, sorry for posting out of the list.
>> >>
>> >> Simple test program is attached. Without your patch timeout expires in
>> >> about 20ms. With it it's ~40ms.
>> >>
>> >> 40 instead of 30 is beacuse of odd tick added by tvtohz().
>> >
>> > Ok, thanks.  tvtohz() will be good to MFC (and I will do that), but for
>> > HEAD I think we can fix this to use a precise timeout.  I've cc'd davide@
>> > so he can take a look at that.
>> >
>> > --
>> > John Baldwin
>>
>> Hi,
>> I think I can switch this code to new timeout KPI, but this will
>> require the timeout field of 'struct sockbuf' to be changed from 'int'
>> to 'sbintime_t' which breaks binary compatibility. Do you have any
>> strong objections about this? If any, I would like this to happen ABI
>> freeze, so it looks like this is the right moment.
>
> This should be fine to change now, it just can't be MFC'd (which we can't
> do anyway).
>
> --
> John Baldwin

Please consider the following patch:
http://people.freebsd.org/~davide/review/socket_timeout.diff
I've tested it and it works OK. I got a timeout which is ~= 25ms using
the testcase provided by the user.
The only doubt I have is about the range check, I've changed a bit
because the 'integer' part of sbintime_t fits in 32-bits, but I'm not
sure it's the best way of doing this.

Thanks,

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about socket timeouts

[John Baldwin]

On Friday, August 23, 2013 9:53:12 am Davide Italiano wrote:
> On Fri, Aug 23, 2013 at 3:45 PM, John Baldwin  wrote:
> > On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote:
> >> 2013/8/22 John Baldwin :
> >> > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote:
> >> >> 2013/8/21 John Baldwin :
> >> >> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote:
> >> >> >> On Mon, 19 Aug 2013, Adrian Chadd wrote:
> >> >> >>
> >> >> >> > Yes! Please file a PR!
> >> >> >>
> >> >> >> This sorta implies that both are acceptable (although,
> >> >> >> the Linux behavior seems more desirable).
> >> >> >>
> >> >> >>http://austingroupbugs.net/view.php?id=369
> >> >> >
> >> >> > No, that says "round up", so it does mean that the requested timeout
> >> >> > should be the minimum amount slept.  tvtohz() does this.  Really odd
> >> >> > that the socket code is using its own version of this rather than
> >> >> > tvtohz().
> >> >> >
> >> >> > Oh, I bet this just predates tvtohz().  Interesting that it keeps 
getting
> >> >> > bug fixes in its history that simply using tvtohz() would have 
solved.
> >> >> >
> >> >> > Try this:
> >> >> >
> >> >> > Index: uipc_socket.c
> >> >> > ===
> >> >> > --- uipc_socket.c   (revision 254570)
> >> >> > +++ uipc_socket.c   (working copy)
> >> >> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt 
*sopt)
> >> >> > if (error)
> >> >> > goto bad;
> >> >> >
> >> >> > -   /* assert(hz > 0); */
> >> >> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX / 
hz ||
> >> >> > tv.tv_usec < 0 || tv.tv_usec >= 100) 
{
> >> >> > error = EDOM;
> >> >> > goto bad;
> >> >> > }
> >> >> > -   /* assert(tick > 0); */
> >> >> > -   /* assert(ULONG_MAX - INT_MAX >= 100); 
*/
> >> >> > -   val = (u_long)(tv.tv_sec * hz) + tv.tv_usec 
/ tick;
> >> >> > -   if (val > INT_MAX) {
> >> >> > +   val = tvtohz(&tv);
> >> >> > +   if (val == INT_MAX) {
> >> >> > error = EDOM;
> >> >> > goto bad;
> >> >> > }
> >> >> > -   if (val == 0 && tv.tv_usec != 0)
> >> >> > -   val = 1;
> >> >> >
> >> >> > switch (sopt->sopt_name) {
> >> >> > case SO_SNDTIMEO:
> >> >> >
> >> >>
> >> >> That must help. But I want to see the issue solved in the next
> >> >> release. I can't apply patch to the production system. Btw in
> >> >> production environment we have kern.hz set to 1000 so it's not a
> >> >> problem there.
> >> >
> >> > Can you test this in some way in a test environment?
> >> >
> >>
> >> Ok, sorry for posting out of the list.
> >>
> >> Simple test program is attached. Without your patch timeout expires in
> >> about 20ms. With it it's ~40ms.
> >>
> >> 40 instead of 30 is beacuse of odd tick added by tvtohz().
> >
> > Ok, thanks.  tvtohz() will be good to MFC (and I will do that), but for
> > HEAD I think we can fix this to use a precise timeout.  I've cc'd davide@
> > so he can take a look at that.
> >
> > --
> > John Baldwin
> 
> Hi,
> I think I can switch this code to new timeout KPI, but this will
> require the timeout field of 'struct sockbuf' to be changed from 'int'
> to 'sbintime_t' which breaks binary compatibility. Do you have any
> strong objections about this? If any, I would like this to happen ABI
> freeze, so it looks like this is the right moment.

This should be fine to change now, it just can't be MFC'd (which we can't
do anyway).

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

Re: Question about socket timeouts

[Vitja Makarov]

2013/8/23 Davide Italiano :
> On Fri, Aug 23, 2013 at 3:45 PM, John Baldwin  wrote:
>> On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote:
>>> 2013/8/22 John Baldwin :
>>> > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote:
>>> >> 2013/8/21 John Baldwin :
>>> >> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote:
>>> >> >> On Mon, 19 Aug 2013, Adrian Chadd wrote:
>>> >> >>
>>> >> >> > Yes! Please file a PR!
>>> >> >>
>>> >> >> This sorta implies that both are acceptable (although,
>>> >> >> the Linux behavior seems more desirable).
>>> >> >>
>>> >> >>http://austingroupbugs.net/view.php?id=369
>>> >> >
>>> >> > No, that says "round up", so it does mean that the requested timeout
>>> >> > should be the minimum amount slept.  tvtohz() does this.  Really odd
>>> >> > that the socket code is using its own version of this rather than
>>> >> > tvtohz().
>>> >> >
>>> >> > Oh, I bet this just predates tvtohz().  Interesting that it keeps 
>>> >> > getting
>>> >> > bug fixes in its history that simply using tvtohz() would have solved.
>>> >> >
>>> >> > Try this:
>>> >> >
>>> >> > Index: uipc_socket.c
>>> >> > ===
>>> >> > --- uipc_socket.c   (revision 254570)
>>> >> > +++ uipc_socket.c   (working copy)
>>> >> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt 
>>> >> > *sopt)
>>> >> > if (error)
>>> >> > goto bad;
>>> >> >
>>> >> > -   /* assert(hz > 0); */
>>> >> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX / hz 
>>> >> > ||
>>> >> > tv.tv_usec < 0 || tv.tv_usec >= 100) {
>>> >> > error = EDOM;
>>> >> > goto bad;
>>> >> > }
>>> >> > -   /* assert(tick > 0); */
>>> >> > -   /* assert(ULONG_MAX - INT_MAX >= 100); */
>>> >> > -   val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / 
>>> >> > tick;
>>> >> > -   if (val > INT_MAX) {
>>> >> > +   val = tvtohz(&tv);
>>> >> > +   if (val == INT_MAX) {
>>> >> > error = EDOM;
>>> >> > goto bad;
>>> >> > }
>>> >> > -   if (val == 0 && tv.tv_usec != 0)
>>> >> > -   val = 1;
>>> >> >
>>> >> > switch (sopt->sopt_name) {
>>> >> > case SO_SNDTIMEO:
>>> >> >
>>> >>
>>> >> That must help. But I want to see the issue solved in the next
>>> >> release. I can't apply patch to the production system. Btw in
>>> >> production environment we have kern.hz set to 1000 so it's not a
>>> >> problem there.
>>> >
>>> > Can you test this in some way in a test environment?
>>> >
>>>
>>> Ok, sorry for posting out of the list.
>>>
>>> Simple test program is attached. Without your patch timeout expires in
>>> about 20ms. With it it's ~40ms.
>>>
>>> 40 instead of 30 is beacuse of odd tick added by tvtohz().
>>
>> Ok, thanks.  tvtohz() will be good to MFC (and I will do that), but for
>> HEAD I think we can fix this to use a precise timeout.  I've cc'd davide@
>> so he can take a look at that.
>>
>> --
>> John Baldwin
>
> Hi,
> I think I can switch this code to new timeout KPI, but this will
> require the timeout field of 'struct sockbuf' to be changed from 'int'
> to 'sbintime_t' which breaks binary compatibility. Do you have any
> strong objections about this? If any, I would like this to happen ABI
> freeze, so it looks like this is the right moment.
>

I think that for socket's timeouts it's ok to have a HZ-precision. It
would be much more important to implement high-precision timeouts for
select() and friends, if it's not done yet (sorry I'm running 9.1).


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

Re: Question about socket timeouts

[Davide Italiano]

On Fri, Aug 23, 2013 at 3:45 PM, John Baldwin  wrote:
> On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote:
>> 2013/8/22 John Baldwin :
>> > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote:
>> >> 2013/8/21 John Baldwin :
>> >> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote:
>> >> >> On Mon, 19 Aug 2013, Adrian Chadd wrote:
>> >> >>
>> >> >> > Yes! Please file a PR!
>> >> >>
>> >> >> This sorta implies that both are acceptable (although,
>> >> >> the Linux behavior seems more desirable).
>> >> >>
>> >> >>http://austingroupbugs.net/view.php?id=369
>> >> >
>> >> > No, that says "round up", so it does mean that the requested timeout
>> >> > should be the minimum amount slept.  tvtohz() does this.  Really odd
>> >> > that the socket code is using its own version of this rather than
>> >> > tvtohz().
>> >> >
>> >> > Oh, I bet this just predates tvtohz().  Interesting that it keeps 
>> >> > getting
>> >> > bug fixes in its history that simply using tvtohz() would have solved.
>> >> >
>> >> > Try this:
>> >> >
>> >> > Index: uipc_socket.c
>> >> > ===
>> >> > --- uipc_socket.c   (revision 254570)
>> >> > +++ uipc_socket.c   (working copy)
>> >> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt 
>> >> > *sopt)
>> >> > if (error)
>> >> > goto bad;
>> >> >
>> >> > -   /* assert(hz > 0); */
>> >> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX / hz ||
>> >> > tv.tv_usec < 0 || tv.tv_usec >= 100) {
>> >> > error = EDOM;
>> >> > goto bad;
>> >> > }
>> >> > -   /* assert(tick > 0); */
>> >> > -   /* assert(ULONG_MAX - INT_MAX >= 100); */
>> >> > -   val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / 
>> >> > tick;
>> >> > -   if (val > INT_MAX) {
>> >> > +   val = tvtohz(&tv);
>> >> > +   if (val == INT_MAX) {
>> >> > error = EDOM;
>> >> > goto bad;
>> >> > }
>> >> > -   if (val == 0 && tv.tv_usec != 0)
>> >> > -   val = 1;
>> >> >
>> >> > switch (sopt->sopt_name) {
>> >> > case SO_SNDTIMEO:
>> >> >
>> >>
>> >> That must help. But I want to see the issue solved in the next
>> >> release. I can't apply patch to the production system. Btw in
>> >> production environment we have kern.hz set to 1000 so it's not a
>> >> problem there.
>> >
>> > Can you test this in some way in a test environment?
>> >
>>
>> Ok, sorry for posting out of the list.
>>
>> Simple test program is attached. Without your patch timeout expires in
>> about 20ms. With it it's ~40ms.
>>
>> 40 instead of 30 is beacuse of odd tick added by tvtohz().
>
> Ok, thanks.  tvtohz() will be good to MFC (and I will do that), but for
> HEAD I think we can fix this to use a precise timeout.  I've cc'd davide@
> so he can take a look at that.
>
> --
> John Baldwin

Hi,
I think I can switch this code to new timeout KPI, but this will
require the timeout field of 'struct sockbuf' to be changed from 'int'
to 'sbintime_t' which breaks binary compatibility. Do you have any
strong objections about this? If any, I would like this to happen ABI
freeze, so it looks like this is the right moment.

Thanks,

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about socket timeouts

[John Baldwin]

On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote:
> 2013/8/22 John Baldwin :
> > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote:
> >> 2013/8/21 John Baldwin :
> >> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote:
> >> >> On Mon, 19 Aug 2013, Adrian Chadd wrote:
> >> >>
> >> >> > Yes! Please file a PR!
> >> >>
> >> >> This sorta implies that both are acceptable (although,
> >> >> the Linux behavior seems more desirable).
> >> >>
> >> >>http://austingroupbugs.net/view.php?id=369
> >> >
> >> > No, that says "round up", so it does mean that the requested timeout
> >> > should be the minimum amount slept.  tvtohz() does this.  Really odd
> >> > that the socket code is using its own version of this rather than
> >> > tvtohz().
> >> >
> >> > Oh, I bet this just predates tvtohz().  Interesting that it keeps getting
> >> > bug fixes in its history that simply using tvtohz() would have solved.
> >> >
> >> > Try this:
> >> >
> >> > Index: uipc_socket.c
> >> > ===
> >> > --- uipc_socket.c   (revision 254570)
> >> > +++ uipc_socket.c   (working copy)
> >> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt *sopt)
> >> > if (error)
> >> > goto bad;
> >> >
> >> > -   /* assert(hz > 0); */
> >> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX / hz ||
> >> > tv.tv_usec < 0 || tv.tv_usec >= 100) {
> >> > error = EDOM;
> >> > goto bad;
> >> > }
> >> > -   /* assert(tick > 0); */
> >> > -   /* assert(ULONG_MAX - INT_MAX >= 100); */
> >> > -   val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / 
> >> > tick;
> >> > -   if (val > INT_MAX) {
> >> > +   val = tvtohz(&tv);
> >> > +   if (val == INT_MAX) {
> >> > error = EDOM;
> >> > goto bad;
> >> > }
> >> > -   if (val == 0 && tv.tv_usec != 0)
> >> > -   val = 1;
> >> >
> >> > switch (sopt->sopt_name) {
> >> > case SO_SNDTIMEO:
> >> >
> >>
> >> That must help. But I want to see the issue solved in the next
> >> release. I can't apply patch to the production system. Btw in
> >> production environment we have kern.hz set to 1000 so it's not a
> >> problem there.
> >
> > Can you test this in some way in a test environment?
> >
> 
> Ok, sorry for posting out of the list.
> 
> Simple test program is attached. Without your patch timeout expires in
> about 20ms. With it it's ~40ms.
> 
> 40 instead of 30 is beacuse of odd tick added by tvtohz().

Ok, thanks.  tvtohz() will be good to MFC (and I will do that), but for
HEAD I think we can fix this to use a precise timeout.  I've cc'd davide@
so he can take a look at that.

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

Re: Question about socket timeouts

[Vitja Makarov]

2013/8/22 John Baldwin :
> On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote:
>> 2013/8/21 John Baldwin :
>> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote:
>> >> On Mon, 19 Aug 2013, Adrian Chadd wrote:
>> >>
>> >> > Yes! Please file a PR!
>> >>
>> >> This sorta implies that both are acceptable (although,
>> >> the Linux behavior seems more desirable).
>> >>
>> >>http://austingroupbugs.net/view.php?id=369
>> >
>> > No, that says "round up", so it does mean that the requested timeout
>> > should be the minimum amount slept.  tvtohz() does this.  Really odd
>> > that the socket code is using its own version of this rather than
>> > tvtohz().
>> >
>> > Oh, I bet this just predates tvtohz().  Interesting that it keeps getting
>> > bug fixes in its history that simply using tvtohz() would have solved.
>> >
>> > Try this:
>> >
>> > Index: uipc_socket.c
>> > ===
>> > --- uipc_socket.c   (revision 254570)
>> > +++ uipc_socket.c   (working copy)
>> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt *sopt)
>> > if (error)
>> > goto bad;
>> >
>> > -   /* assert(hz > 0); */
>> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX / hz ||
>> > tv.tv_usec < 0 || tv.tv_usec >= 100) {
>> > error = EDOM;
>> > goto bad;
>> > }
>> > -   /* assert(tick > 0); */
>> > -   /* assert(ULONG_MAX - INT_MAX >= 100); */
>> > -   val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / tick;
>> > -   if (val > INT_MAX) {
>> > +   val = tvtohz(&tv);
>> > +   if (val == INT_MAX) {
>> > error = EDOM;
>> > goto bad;
>> > }
>> > -   if (val == 0 && tv.tv_usec != 0)
>> > -   val = 1;
>> >
>> > switch (sopt->sopt_name) {
>> > case SO_SNDTIMEO:
>> >
>>
>> That must help. But I want to see the issue solved in the next
>> release. I can't apply patch to the production system. Btw in
>> production environment we have kern.hz set to 1000 so it's not a
>> problem there.
>
> Can you test this in some way in a test environment?
>

Ok, sorry for posting out of the list.

Simple test program is attached. Without your patch timeout expires in
about 20ms. With it it's ~40ms.

40 instead of 30 is beacuse of odd tick added by tvtohz().

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

Re: Question about socket timeouts

[John Baldwin]

On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote:
> On Mon, 19 Aug 2013, Adrian Chadd wrote:
> 
> > Yes! Please file a PR!
> 
> This sorta implies that both are acceptable (although,
> the Linux behavior seems more desirable).
> 
>http://austingroupbugs.net/view.php?id=369

No, that says "round up", so it does mean that the requested timeout
should be the minimum amount slept.  tvtohz() does this.  Really odd
that the socket code is using its own version of this rather than
tvtohz().

Oh, I bet this just predates tvtohz().  Interesting that it keeps getting
bug fixes in its history that simply using tvtohz() would have solved.

Try this:

Index: uipc_socket.c
===
--- uipc_socket.c   (revision 254570)
+++ uipc_socket.c   (working copy)
@@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt *sopt)
if (error)
goto bad;
 
-   /* assert(hz > 0); */
if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX / hz ||
tv.tv_usec < 0 || tv.tv_usec >= 100) {
error = EDOM;
goto bad;
}
-   /* assert(tick > 0); */
-   /* assert(ULONG_MAX - INT_MAX >= 100); */
-   val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / tick;
-   if (val > INT_MAX) {
+   val = tvtohz(&tv);
+   if (val == INT_MAX) {
error = EDOM;
goto bad;
}
-   if (val == 0 && tv.tv_usec != 0)
-   val = 1;
 
switch (sopt->sopt_name) {
case SO_SNDTIMEO:


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

Re: Question about socket timeouts

[Daniel Eischen]

On Mon, 19 Aug 2013, Adrian Chadd wrote:


Yes! Please file a PR!


This sorta implies that both are acceptable (although,
the Linux behavior seems more desirable).

  http://austingroupbugs.net/view.php?id=369


On 19 August 2013 12:33, Vitja Makarov  wrote:


Hi!

Recently I was playing with small socket timeouts. setsockopt(2)
SO_RCVTIMEO and found a problem with it: if timeout is small enough
read(2) may return before timeout is actually expired.

I was unable to reproduce this on linux box.

I found that kernel uses a timer with 1/HZ precision so it converts
time in microseconds to ticks that's ok linux does it as well. The
problem is in details: freebsd uses floor() approach while linux uses
ceil():

from FreeBSD's sys/kern/uipc_socket.c:
val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / tick;
if (val == 0 && tv.tv_usec != 0)
 val = 1; /* at least one tick if tv > 0 */

from Linux's net/core/sock.c:
*timeo_p = tv.tv_sec*HZ + (tv.tv_usec+(100/HZ-1))/(100/HZ);

So, for instance, we have a freebsd system running with kern.hz set
100 and set receive timeout to 25ms that is converted to 2 ticks which
is 20ms. In my test program read(2) returns with EAGAIN set in
0.019ms.

So the question is: is that a problem or not?

--
vitja.


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

Re: Question about socket timeouts

[Adrian Chadd]

Yes! Please file a PR!



-adrian



On 19 August 2013 12:33, Vitja Makarov  wrote:

> Hi!
>
> Recently I was playing with small socket timeouts. setsockopt(2)
> SO_RCVTIMEO and found a problem with it: if timeout is small enough
> read(2) may return before timeout is actually expired.
>
> I was unable to reproduce this on linux box.
>
> I found that kernel uses a timer with 1/HZ precision so it converts
> time in microseconds to ticks that's ok linux does it as well. The
> problem is in details: freebsd uses floor() approach while linux uses
> ceil():
>
> from FreeBSD's sys/kern/uipc_socket.c:
> val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / tick;
> if (val == 0 && tv.tv_usec != 0)
>  val = 1; /* at least one tick if tv > 0 */
>
> from Linux's net/core/sock.c:
> *timeo_p = tv.tv_sec*HZ + (tv.tv_usec+(100/HZ-1))/(100/HZ);
>
> So, for instance, we have a freebsd system running with kern.hz set
> 100 and set receive timeout to 25ms that is converted to 2 ticks which
> is 20ms. In my test program read(2) returns with EAGAIN set in
> 0.019ms.
>
> So the question is: is that a problem or not?
>
> --
> vitja.
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about portsdb (part of ports-mgmt/portupgrade)

[Matthew D. Fuller]

On Sat, Jun 22, 2013 at 12:34:38PM + I heard the voice of
Walter Hurry, and lo! it spake thus:
> 
> But the corresponding action doesn't happen on 10.0-CURRENT
> (r251572) until I do a 'portsdb -Fu'.
> 
> Why the difference?

Portsnap doesn't make/distribute INDEX-10 (until 10 spirals toward
-STABLE status, anyway).  I just symlink it to INDEX-9...


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question on building from sources.

[Super Bisquit]

Make fetch-recursive stops due to the vulnerability found in perl versions
5.8 to 5.16.3.  What's the current status?
Are there any patches?



On Sat, Mar 30, 2013 at 8:10 PM, Erich Dollansky <
erichsfreebsdl...@alogt.com> wrote:

> Hi,
>
> On Sat, 30 Mar 2013 19:05:47 -0400
> Super Bisquit  wrote:
>
> > Okay. I already have 10.0 on the machine from a year ago. What I have
>
> this sounds a bit old.
>
> > come up against is CLANG_IS_CC ="no" when trying to build run(4).
> > What is the current state of clang as cc compiler on ppc32? <-- This
> > needs to be fixed first.
>
> I do not use FreeBSD on any thing else but AMD64.
>
> > Thanks for the replies and sorry for any noise.
>
> Isn't the noise the idea behind this mailing list?
>
> Erich
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question on building from sources.

[Erich Dollansky]

Hi,

On Sat, 30 Mar 2013 19:05:47 -0400
Super Bisquit  wrote:

> Okay. I already have 10.0 on the machine from a year ago. What I have

this sounds a bit old.

> come up against is CLANG_IS_CC ="no" when trying to build run(4).
> What is the current state of clang as cc compiler on ppc32? <-- This
> needs to be fixed first.

I do not use FreeBSD on any thing else but AMD64.

> Thanks for the replies and sorry for any noise.

Isn't the noise the idea behind this mailing list?

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

Re: Question on building from sources.

[Super Bisquit]

That was the error that came up, apologies for not specifying such. I'm not
trying to disable clang but am trying to build the system using what is
there.

This is about the time I need a powerpc laptop or a connection..



On Sat, Mar 30, 2013 at 7:09 PM, Glen Barber  wrote:

> On Sat, Mar 30, 2013 at 07:05:47PM -0400, Super Bisquit wrote:
> > Okay. I already have 10.0 on the machine from a year ago. What I have
> come
> > up against is CLANG_IS_CC ="no" when trying to build run(4).
>
> If you are trying to disable clang, you want to use:
>
> WITHOUT_CLANG_IS_CC=yes
>
> > What is the current state of clang as cc compiler on ppc32? <-- This
> needs
> > to be fixed first.
>
> I am not aware of any problems.
>
> Glen
>
> > Thanks for the replies and sorry for any noise.
> >
> >
> >
> > On Fri, Mar 29, 2013 at 10:33 PM, Erich Dollansky <
> > erichsfreebsdl...@alogt.com> wrote:
> >
> > > Hi,
> > >
> > > On Fri, 29 Mar 2013 22:03:11 -0400
> > > Glen Barber  wrote:
> > >
> > > > On Fri, Mar 29, 2013 at 09:31:12PM -0400, Super Bisquit wrote:
> > > > > I have my QuickSilver and no internet connection. I have a few
> > > > > questions. 1. Do I download the latest for PowerPC(32bit) and then
> > > > > download the sources according to the Makefile.
> > > >
> > > > For ports, yes, you will to do 'make fetch' or 'make fetch-recursive'
> > > > for third-party software you want to install.
> > > >
> > > yes.
> > >
> > > > > 3. Has anyone else done this before? If yes, then what were your
> > > > > results?
> > > > >
> > > >
> > > > It is painful.  My suggestion is to identify everything you
> absolutely
> > > > need, and do from a separate machine with internet access:
> > > >
> > > I do this all the while as I have only random Internet connection. But
> > > I do this only for amd64. It works most of the time. Expect some
> > > returns to the machine with an Internet connection.
> > >
> > > > Note that if anything is missing, build will fail at compile time on
> > > > the internet-less machine.
> > >
> > > This should only be a problem for the ports. The sources can easily be
> > > downloaded in one go.
> > >
> > > Erich
> > >
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question on building from sources.

[Glen Barber]

On Sat, Mar 30, 2013 at 07:05:47PM -0400, Super Bisquit wrote:
> Okay. I already have 10.0 on the machine from a year ago. What I have come
> up against is CLANG_IS_CC ="no" when trying to build run(4).

If you are trying to disable clang, you want to use:

WITHOUT_CLANG_IS_CC=yes

> What is the current state of clang as cc compiler on ppc32? <-- This needs
> to be fixed first.

I am not aware of any problems.

Glen

> Thanks for the replies and sorry for any noise.
> 
> 
> 
> On Fri, Mar 29, 2013 at 10:33 PM, Erich Dollansky <
> erichsfreebsdl...@alogt.com> wrote:
> 
> > Hi,
> >
> > On Fri, 29 Mar 2013 22:03:11 -0400
> > Glen Barber  wrote:
> >
> > > On Fri, Mar 29, 2013 at 09:31:12PM -0400, Super Bisquit wrote:
> > > > I have my QuickSilver and no internet connection. I have a few
> > > > questions. 1. Do I download the latest for PowerPC(32bit) and then
> > > > download the sources according to the Makefile.
> > >
> > > For ports, yes, you will to do 'make fetch' or 'make fetch-recursive'
> > > for third-party software you want to install.
> > >
> > yes.
> >
> > > > 3. Has anyone else done this before? If yes, then what were your
> > > > results?
> > > >
> > >
> > > It is painful.  My suggestion is to identify everything you absolutely
> > > need, and do from a separate machine with internet access:
> > >
> > I do this all the while as I have only random Internet connection. But
> > I do this only for amd64. It works most of the time. Expect some
> > returns to the machine with an Internet connection.
> >
> > > Note that if anything is missing, build will fail at compile time on
> > > the internet-less machine.
> >
> > This should only be a problem for the ports. The sources can easily be
> > downloaded in one go.
> >
> > Erich
> >


pgpykt_BW1Qee.pgp
Description: PGP signature

Re: Question on building from sources.

[Super Bisquit]

Okay. I already have 10.0 on the machine from a year ago. What I have come
up against is CLANG_IS_CC ="no" when trying to build run(4).
What is the current state of clang as cc compiler on ppc32? <-- This needs
to be fixed first.
Thanks for the replies and sorry for any noise.



On Fri, Mar 29, 2013 at 10:33 PM, Erich Dollansky <
erichsfreebsdl...@alogt.com> wrote:

> Hi,
>
> On Fri, 29 Mar 2013 22:03:11 -0400
> Glen Barber  wrote:
>
> > On Fri, Mar 29, 2013 at 09:31:12PM -0400, Super Bisquit wrote:
> > > I have my QuickSilver and no internet connection. I have a few
> > > questions. 1. Do I download the latest for PowerPC(32bit) and then
> > > download the sources according to the Makefile.
> >
> > For ports, yes, you will to do 'make fetch' or 'make fetch-recursive'
> > for third-party software you want to install.
> >
> yes.
>
> > > 3. Has anyone else done this before? If yes, then what were your
> > > results?
> > >
> >
> > It is painful.  My suggestion is to identify everything you absolutely
> > need, and do from a separate machine with internet access:
> >
> I do this all the while as I have only random Internet connection. But
> I do this only for amd64. It works most of the time. Expect some
> returns to the machine with an Internet connection.
>
> > Note that if anything is missing, build will fail at compile time on
> > the internet-less machine.
>
> This should only be a problem for the ports. The sources can easily be
> downloaded in one go.
>
> Erich
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question on building from sources.

[Erich Dollansky]

Hi,

On Fri, 29 Mar 2013 22:03:11 -0400
Glen Barber  wrote:

> On Fri, Mar 29, 2013 at 09:31:12PM -0400, Super Bisquit wrote:
> > I have my QuickSilver and no internet connection. I have a few
> > questions. 1. Do I download the latest for PowerPC(32bit) and then
> > download the sources according to the Makefile.
> 
> For ports, yes, you will to do 'make fetch' or 'make fetch-recursive'
> for third-party software you want to install.
> 
yes.

> > 3. Has anyone else done this before? If yes, then what were your
> > results?
> > 
> 
> It is painful.  My suggestion is to identify everything you absolutely
> need, and do from a separate machine with internet access:
> 
I do this all the while as I have only random Internet connection. But
I do this only for amd64. It works most of the time. Expect some
returns to the machine with an Internet connection.

> Note that if anything is missing, build will fail at compile time on
> the internet-less machine.

This should only be a problem for the ports. The sources can easily be
downloaded in one go.

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

Re: Question on building from sources.

[Glen Barber]

On Fri, Mar 29, 2013 at 09:31:12PM -0400, Super Bisquit wrote:
> I have my QuickSilver and no internet connection. I have a few questions.
> 1. Do I download the latest for PowerPC(32bit) and then download the
> sources according to the Makefile.

For ports, yes, you will to do 'make fetch' or 'make fetch-recursive'
for third-party software you want to install.

> 2. Will I need to skip checking the hash/md sum so that the
> applications can build?

No.  Hashes are generated locally and compared against information in
the distinfo file.  If there is a mismatch, that is a bug.

> 3. Has anyone else done this before? If yes, then what were your results?
> 

It is painful.  My suggestion is to identify everything you absolutely
need, and do from a separate machine with internet access:

# sh -c 'for i in `make -C /usr/ports/category/port all-depends-list`; \
do make -C $i fetch-recursive; \
done

Note that if anything is missing, build will fail at compile time on the
internet-less machine.

Glen



pgpWklgaFfU7s.pgp
Description: PGP signature

Re: nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII]

[Damien Fleuriot]

On 15 Oct 2011, at 22:56, Marius Strobl  wrote:

> 
> Could owners of nge(4), tl(4), wb(4) and rl(4) driven hardware (as for
> rl(4) only 8129 need testing, 8139 don't) please give the following
> patch a try in order to ensure it doesn't break anything?
> for 9/head:
> http://people.freebsd.org/~marius/mii_bitbang.diff
> for 8:
> http://people.freebsd.org/~marius/mii_bitbang.diff8
> 
> Thanks,
> Marius
> 


While I don't have any box with this hardware, I'm thinking you might want to 
get a bit more specific about what you want tested...

What do you think the patch might break ?

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

Re: nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII]

[Marius Strobl]

On Sun, Oct 16, 2011 at 02:46:23AM +0200, Damien Fleuriot wrote:
> 
> 
> On 15 Oct 2011, at 22:56, Marius Strobl  wrote:
> 
> > 
> > Could owners of nge(4), tl(4), wb(4) and rl(4) driven hardware (as for
> > rl(4) only 8129 need testing, 8139 don't) please give the following
> > patch a try in order to ensure it doesn't break anything?
> > for 9/head:
> > http://people.freebsd.org/~marius/mii_bitbang.diff
> > for 8:
> > http://people.freebsd.org/~marius/mii_bitbang.diff8
> > 
> > Thanks,
> > Marius
> > 
> 
> 
> While I don't have any box with this hardware, I'm thinking you might want to 
> get a bit more specific about what you want tested...
> 
> What do you think the patch might break ?
> 

Basically, if there's something wrong with the patch the driver should
fail to attach, if it still does and gets a link all should be fine.

Marius

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

nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII]

[Marius Strobl]

Could owners of nge(4), tl(4), wb(4) and rl(4) driven hardware (as for
rl(4) only 8129 need testing, 8139 don't) please give the following
patch a try in order to ensure it doesn't break anything?
for 9/head:
http://people.freebsd.org/~marius/mii_bitbang.diff
for 8:
http://people.freebsd.org/~marius/mii_bitbang.diff8

Thanks,
Marius

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

Re: Question on freeBSD (5.1-CURRENT) portupgrade of Perl 5.8 andlibiconv 1.9.1_3

[Szilveszter Adam]

Hello,

On Wed, Oct 22, 2003 at 01:21:10AM -0400, Joe Marcus Clarke wrote:
> On Wed, 2003-10-22 at 01:14, Scott W wrote:
> > Also, is there a way to pass configure options to portupgrade, or should 
> > I run make clean && ./configure for each port in an 'upgrade chain' and 
> > then force portupgrade to not make clean prior to building/installing?
> 
> Configure arguments?  No.  However, you can use the -m option to pass
> make arguments (e.g. -DWITH_FOO).  To pass configure arguments, you'd
> have to edit the port Makefiles directly.

There is an easier way: you can use CONFIGURE_* variables, which can
also be defined on the command line. For documentation on these and on
the Makefile format for ports, see the Porters Handbook.

There is also pkgtools.conf, as has been noted.

Hope this helps.

-- 
Regards:

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

Re: Question on freeBSD (5.1-CURRENT) portupgrade of Perl5.8andlibiconv 1.9.1_3

[Putinas]

if you use portupgrade and you want to pass make arguments you should look at 
/usr/local/etc/pkgtools.conf 
my example  :
  MAKE_ARGS = {
'irc/bitchx-*' => 'WITH_SSL=1 WITH_IPV6=1',
'net/samba*' => 'WITHOUT_CUPS=1',
'databases/mysql323-server*' => 'SKIP_INSTALL_DB=1',
'ftp/proftpd*' => 'WITHOUT_PAM=1',
  }

after you setup it for your needs - your life become pretty easy with portupgrading ...
- Original Message - 
From: "Scott Wegener, Roadster Performance" <[EMAIL PROTECTED]>
To: "Joe Marcus Clarke" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Scott W" <[EMAIL PROTECTED]>
Sent: Wednesday, October 22, 2003 07:34 AM
Subject: Re: Question on freeBSD (5.1-CURRENT) portupgrade of Perl5.8andlibiconv 
1.9.1_3


> Joe Marcus Clarke wrote:
> 
> >On Wed, 2003-10-22 at 01:14, Scott W wrote:
> >  
> >
> >>Hey all.  In doing a portupgrade -RvN for windowmaker, Perl and libiconv 
> >>were recompiled.  I saved the log output and noticed several oddities I 
> >>was wondering if anyone can explain?
> >>
> >>1..several settings come up as undefined during the Perl build, namely:
> >>$i_malloc
> >>$d_setegid
> >>$d_seteuid
> >>$i_iconv
> >>
> >>These don't look troubling by themselves dur to 'autoconf magic,' but 
> >>the next one for libiconv is more bothersome:
> >>
> >> From libiconv 1.9.1_3 configure:
> >>checking if libtool supports shared libraries... yes
> >>
> >>*** Warning: the command libtool uses to detect shared libraries,
> >>*** /usr/bin/file, produces output that libtool cannot recognize.
> >>*** The result is that libtool may fail to recognize shared libraries
> >>*** as such.  This will affect the creation of libtool libraries that
> >>*** depend on shared libraries, but programs linked with such libtool
> >>*** libraries will work regardless of this problem.  Nevertheless, you
> >>*** may want to report the problem to your system manager and/or to
> >>*** [EMAIL PROTECTED]
> >>
> >>Any ideas?
> >>
> >>
> >
> >This is a byproduct of the new dynamic root layout in -CURRENT. 
> >Basically, older versions of libtool try to do file on
> >/usr/lib/libc.so.  Recent versions of -CURRENT put libc.so in /lib. 
> >Therefore, this fails.  I haven't noticed any real problems because of
> >this, but I have reported it to the libtool maintainer, [EMAIL PROTECTED]
> >  
> >
> Great.  That makes sense, as file will return symbolic link rather than 
> an ELF executable, should be a minor adjustment by the maintainer.  Also 
> makes sense on libc in /lib - always disturbs me when I see 'important' 
> system binaries mounted on the /usr filesystem!
> 
> >>Also, is there a way to pass configure options to portupgrade, or should 
> >>I run make clean && ./configure for each port in an 'upgrade chain' and 
> >>then force portupgrade to not make clean prior to building/installing?
> >>
> >>
> >
> >Configure arguments?  No.  However, you can use the -m option to pass
> >make arguments (e.g. -DWITH_FOO).  To pass configure arguments, you'd
> >have to edit the port Makefiles directly.
> >
> >Joe
> >  
> >
> 
> Actually, it _looks_ like there's somewhat of a standard in place within 
> the port Makefiles defining CONFIGURE_ARGS, but I haven't searched 
> through all of them- anyone know if this is a 'freeBSD Makefile 
> standard' that can (generally) be counted on?  If so, at least for 
> specific ports builds, you should be able to define it on the command 
> line to make (as Joe stated) or via passing the parameter to make for 
> portupgradealthough that change doesn't get saved anywhere and will 
> be clobbered by the next cvsup- any clean way to avoid this?  I need to 
> build apache for this system at some point, and somehow I'm not just 
> seeing the defaults as likely to 'fit everyone' on that one?
> 
> Thanks again,
> 
> Scott
> 
> >>Thanks,
> >>
> >>Scott
> >>
> >>___
> >>[EMAIL PROTECTED] mailing list
> >>http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> >>To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> >>
> >>
> 
> 
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> 
> ___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Question on freeBSD (5.1-CURRENT) portupgrade of Perl 5.8andlibiconv 1.9.1_3

[Scott Wegener, Roadster Performance]

Joe Marcus Clarke wrote:

On Wed, 2003-10-22 at 01:14, Scott W wrote:
 

Hey all.  In doing a portupgrade -RvN for windowmaker, Perl and libiconv 
were recompiled.  I saved the log output and noticed several oddities I 
was wondering if anyone can explain?

1..several settings come up as undefined during the Perl build, namely:
$i_malloc
$d_setegid
$d_seteuid
$i_iconv
These don't look troubling by themselves dur to 'autoconf magic,' but 
the next one for libiconv is more bothersome:

From libiconv 1.9.1_3 configure:
checking if libtool supports shared libraries... yes
*** Warning: the command libtool uses to detect shared libraries,
*** /usr/bin/file, produces output that libtool cannot recognize.
*** The result is that libtool may fail to recognize shared libraries
*** as such.  This will affect the creation of libtool libraries that
*** depend on shared libraries, but programs linked with such libtool
*** libraries will work regardless of this problem.  Nevertheless, you
*** may want to report the problem to your system manager and/or to
*** [EMAIL PROTECTED]
Any ideas?
   

This is a byproduct of the new dynamic root layout in -CURRENT. 
Basically, older versions of libtool try to do file on
/usr/lib/libc.so.  Recent versions of -CURRENT put libc.so in /lib. 
Therefore, this fails.  I haven't noticed any real problems because of
this, but I have reported it to the libtool maintainer, [EMAIL PROTECTED]
 

Great.  That makes sense, as file will return symbolic link rather than 
an ELF executable, should be a minor adjustment by the maintainer.  Also 
makes sense on libc in /lib - always disturbs me when I see 'important' 
system binaries mounted on the /usr filesystem!

Also, is there a way to pass configure options to portupgrade, or should 
I run make clean && ./configure for each port in an 'upgrade chain' and 
then force portupgrade to not make clean prior to building/installing?
   

Configure arguments?  No.  However, you can use the -m option to pass
make arguments (e.g. -DWITH_FOO).  To pass configure arguments, you'd
have to edit the port Makefiles directly.
Joe
 

Actually, it _looks_ like there's somewhat of a standard in place within 
the port Makefiles defining CONFIGURE_ARGS, but I haven't searched 
through all of them- anyone know if this is a 'freeBSD Makefile 
standard' that can (generally) be counted on?  If so, at least for 
specific ports builds, you should be able to define it on the command 
line to make (as Joe stated) or via passing the parameter to make for 
portupgradealthough that change doesn't get saved anywhere and will 
be clobbered by the next cvsup- any clean way to avoid this?  I need to 
build apache for this system at some point, and somehow I'm not just 
seeing the defaults as likely to 'fit everyone' on that one?

Thanks again,

Scott

Thanks,

Scott

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



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

Re: Question on freeBSD (5.1-CURRENT) portupgrade of Perl 5.8 andlibiconv 1.9.1_3

[Joe Marcus Clarke]

On Wed, 2003-10-22 at 01:14, Scott W wrote:
> Hey all.  In doing a portupgrade -RvN for windowmaker, Perl and libiconv 
> were recompiled.  I saved the log output and noticed several oddities I 
> was wondering if anyone can explain?
> 
> 1..several settings come up as undefined during the Perl build, namely:
> $i_malloc
> $d_setegid
> $d_seteuid
> $i_iconv
> 
> These don't look troubling by themselves dur to 'autoconf magic,' but 
> the next one for libiconv is more bothersome:
> 
>  From libiconv 1.9.1_3 configure:
> checking if libtool supports shared libraries... yes
> 
> *** Warning: the command libtool uses to detect shared libraries,
> *** /usr/bin/file, produces output that libtool cannot recognize.
> *** The result is that libtool may fail to recognize shared libraries
> *** as such.  This will affect the creation of libtool libraries that
> *** depend on shared libraries, but programs linked with such libtool
> *** libraries will work regardless of this problem.  Nevertheless, you
> *** may want to report the problem to your system manager and/or to
> *** [EMAIL PROTECTED]
> 
> Any ideas?

This is a byproduct of the new dynamic root layout in -CURRENT. 
Basically, older versions of libtool try to do file on
/usr/lib/libc.so.  Recent versions of -CURRENT put libc.so in /lib. 
Therefore, this fails.  I haven't noticed any real problems because of
this, but I have reported it to the libtool maintainer, [EMAIL PROTECTED]

> 
> Also, is there a way to pass configure options to portupgrade, or should 
> I run make clean && ./configure for each port in an 'upgrade chain' and 
> then force portupgrade to not make clean prior to building/installing?

Configure arguments?  No.  However, you can use the -m option to pass
make arguments (e.g. -DWITH_FOO).  To pass configure arguments, you'd
have to edit the port Makefiles directly.

Joe

> 
> Thanks,
> 
> Scott
> 
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
-- 
PGP Key : http://www.marcuscom.com/pgp.asc


signature.asc
Description: This is a digitally signed message part

Re: Question related to FreeBSD Serial Console...

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Gordon Tetlow <[EMAIL PROTECTED]> writes:
: I've personally killed about 5 keyboards this way. I don't recommend hot
: plugging PS/2 keyboards.

PS/2 keyboards and mice are not hot pluggable.  Mechanical switches do
not meet the spec, but are less bad than actual hot plugging.  The
fact that you can often get away with it makes people think it is ok.

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

Re: Question related to FreeBSD Serial Console...

[Gordon Tetlow]

On Tue, Sep 02, 2003 at 12:18:51PM +0100, [EMAIL PROTECTED] wrote:
> Hiya
> 
> 
> > Unfortunately, many motherboards (BIOSs?) won't initialise a PS/2 keyboard
> > interface unless a keyboard is connected at boot time, so if you plug in a
> > keyboard subsequently it won't work. Nothing the OS can do in this case (I
> > believe), and yes it's a PITA.
> 
> Keyboard and mouse manufacturers usually give dire warnings about plugging
> in PS/2 devices when the machine is powered up, maybe that's the reason
> why.

I've personally killed about 5 keyboards this way. I don't recommend hot
plugging PS/2 keyboards.

-gordon


pgp0.pgp
Description: PGP signature

Re: Question about genassym, locore.s and 0-sized arrays(showstopper for an icc compiled kernel)

[Marcel Moolenaar]

On Sat, Sep 06, 2003 at 10:57:52AM +0200, Alexander Leidinger wrote:
> 
> ---snip---
> %  #include 
> 
> struct foo {
> int tag;
> char obj[];
> };
> 
> int main(void) {
> struct foo bar;
> 
> printf("%d\n", sizeof(struct foo));
> printf("%d\n", sizeof(bar));
> 
> return 0;
> }
> 
> % ./a.out 
> 4
> 4
> ---snip---

The compiler seems to behave correctly WRT C99. However, when
presented with code that uses extensions the compiler behaves
inconsistently or erratically. If the compiler cannot do any-
thing useful with zero-sized arrays, it should reject them
completely. Only then can one reasonably fall back on C99 to
explain the behaviour of the compiler. However, since the
compiler accepts zero-sized arrays, it is already in violation
with C99 and one cannot use C99 as a basis to explain the
any behaviour of the compiler in the context of the non-compliant
construct. The creation of single-element array instead of
the declared zero-element array is downright broken.

My $0.02

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

Re: Question about genassym, locore.s and 0-sized arrays(showstopper for an icc compiled kernel)

[Alexander Leidinger]

On Sat, 6 Sep 2003 01:42:59 -0700
John-Mark Gurney <[EMAIL PROTECTED]> wrote:

> Alexander Leidinger wrote this message on Sat, Sep 06, 2003 at 10:33 +0200:
> > struct {
> ^ try moving foo to here.
> > int tag;
> > char obj[];
> > } foo;
> ^^^ from here.
> 

Uhm... yes, sorry.

---snip---
% 

struct foo {
int tag;
char obj[];
};

int main(void) {
struct foo bar;

printf("%d\n", sizeof(struct foo));
printf("%d\n", sizeof(bar));

return 0;
}

% ./a.out 
4
4
---snip---

Bye,
Alexander.

-- 
Yes, I've heard of "decaf." What's your point?

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Question about genassym, locore.s and 0-sized arrays(showstopper for an icc compiled kernel)

[John-Mark Gurney]

Alexander Leidinger wrote this message on Sat, Sep 06, 2003 at 10:33 +0200:
> struct {
^ try moving foo to here.
> int tag;
> char obj[];
> } foo;
^^^ from here.

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Question about genassym, locore.s and 0-sized arrays(showstopper for an icc compiled kernel)

[Alexander Leidinger]

On Fri, 5 Sep 2003 09:55:57 -0700
Marcel Moolenaar <[EMAIL PROTECTED]> wrote:

> Interesting, What does icc do with:
> 
> struct {
>   int tag;
>   char obj[];
> } foo;
> 
> And what does the sizeof() operator give.

---snip---
% 

struct {
int tag;
char obj[];
} foo;

int main(void) {
struct foo bar;

printf("%d\n", sizeof(struct foo));
printf("%d\n", sizeof(bar));
return 0;
}


% icc marcel.c
marcel.c(9): error: incomplete type is not allowed
struct foo bar;
   ^

marcel.c(11): warning #70: incomplete type is not allowed
printf("%d\n", sizeof(struct foo));
  ^

compilation aborted for marcel.c (code 2)

% 

struct {
int tag;
char obj[];
} foo;

int main(void) {
printf("%d\n", sizeof(struct foo));
return 0;
}

% icc marcel.c
marcel.c(9): warning #70: incomplete type is not allowed
printf("%d\n", sizeof(struct foo));
  ^
% ./a.out 
0
---snip---

Bye,
Alexander.

-- 
  Loose bits sink chips.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Question about genassym, locore.s and 0-sized arrays(showstopper for an icc compiled kernel)

[Marcel Moolenaar]

On Fri, Sep 05, 2003 at 10:55:07AM +0200, Alexander Leidinger wrote:
> > 
> > It does, according to my reading of it.  They may have an issue with
> > dead code removal or element aliasing.  The way to find out would be
> > to see what they emit for "[]"... 0 lenth, or 1?
> 
> %  char array[];
> 
> % nm icc.o
> 0001 C array

Interesting, What does icc do with:

struct {
int tag;
char obj[];
} foo;

And what does the sizeof() operator give.

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

Re: Question about genassym, locore.s and 0-sized arrays(showstopper for an icc compiled kernel)

[Marius Strobl]

On Fri, Sep 05, 2003 at 07:34:39PM +1000, Bruce Evans wrote:
> On Fri, 5 Sep 2003, I wrote:
> 
> > ...
> > If some values are unrepresentable then they need to be represtended
> > using other values.  E.g., add 1 to avoid 0, or multiply by the alignment
> > size if some element of the tool chanin instsists on rounding up things
>chain  insists
> > for alignment like a broken aout version used to do.  16-bit values
> > would need 17 bits to represent after adding 1.
> 
> Better, add 0x1 to avoid 0.  awk has no support for parsing hex numbers
> so subtracting the bias of 1 would take a lot more code, but ignoring
> leading hexdigits requires no changes in genassym.sh -- it already ignores
> everything except the last 4 hexdigits.
> 

This works, too. Thanks for the detailed explanation Bruce!

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

Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)

[Stefan Farfeleder]

On Thu, Sep 04, 2003 at 11:28:58AM -0500, Dan Nelson wrote:
> In the last episode (Sep 04), Alexander Leidinger said:

> >  - If we depend on it: how hard would it be to rewrite it to not depend
> >on 0-sized arrays (and does someone volunteer to rewrite it)? It
> >would be nice if someone could point me to the source if it isn't
> >an easy task, my contact @Intel is willing to convince the
> >developers to change icc, but he has to "present a persuasive
> >argument to development to pursue a solution".
> 
> If you're talking FreeBSD 5, you should be able to simply subsitute a
> C99 "flexible array member" (basically replace "[0]" with "[]") and get
> the same effect.  0-length arrays are a gcc extension:

But even with flexible array members you cannot create an object with
size 0.  The struct must have at least one additional member and you
cannot use sizeof on the flexible array member itself as its type is
incomplete.

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

Re: Question about genassym, locore.s and 0-sizedarrays(showstopper for an icc compiled kernel)

[Alexander Leidinger]

On Fri, 05 Sep 2003 02:06:56 -0700
Terry Lambert <[EMAIL PROTECTED]> wrote:

> Now try:
> 
>   struct foo {
>   char c;
>   int i;
>   long array[];
>   };
> 
>   struct foo foo;m
>   struct foo fee[1];
>   struct foo fie[3];
>   struct foo foe[0];
>   struct foo fum[1];
> 
> on both compilers.  If they end up the same, then Intel needs to
> change to using the 0.  If they end up different, then they are
> broken relative to the C99 standard and zero length arrays a final
> elements in structures.

% icc -c terry.c
terry.c(8): warning #1229: type containing an unknown-size array may alias another 
element
struct foo fee[1];
   ^

terry.c(9): warning #1229: type containing an unknown-size array may alias another 
element
struct foo fie[3];
   ^

terry.c(10): warning #1229: type containing an unknown-size array may alias another 
element
struct foo foe[0];
   ^

terry.c(11): warning #1229: type containing an unknown-size array may alias another 
element
struct foo fum[1];
   ^

icc:
0008 C fee
0018 C fie
0008 C foe
0008 C foo
0008 C fum

gcc:
0008 C fee
0018 C fie
 C foe
0008 C foo
0008 C fum

Bye,
Alexander.

-- 
Where do you think you're going today?

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Question about genassym, locore.s and 0-sizedarrays(showstopper for an icc compiled kernel)

[Bruce Evans]

On Fri, 5 Sep 2003, I wrote:

> ...
> If some values are unrepresentable then they need to be represtended
> using other values.  E.g., add 1 to avoid 0, or multiply by the alignment
> size if some element of the tool chanin instsists on rounding up things
   chain  insists
> for alignment like a broken aout version used to do.  16-bit values
> would need 17 bits to represent after adding 1.

Better, add 0x1 to avoid 0.  awk has no support for parsing hex numbers
so subtracting the bias of 1 would take a lot more code, but ignoring
leading hexdigits requires no changes in genassym.sh -- it already ignores
everything except the last 4 hexdigits.

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

Re: Question about genassym, locore.s and 0-sizedarrays(showstopperfor an icc compiled kernel)

[Terry Lambert]

Alexander Leidinger wrote:
> On Fri, 05 Sep 2003 01:38:29 -0700
> Terry Lambert <[EMAIL PROTECTED]> wrote:
> > Dan Nelson wrote:
> > > I guess the correct question to be asking is "does the ELF format allow
> > > 0-length symbols?"
> >
> > It does, according to my reading of it.  They may have an issue with
> > dead code removal or element aliasing.  The way to find out would be
> > to see what they emit for "[]"... 0 lenth, or 1?
> 
> %  char array[];
> 
> % nm icc.o
> 0001 C array

Now try:

struct foo {
char c;
int i;
long array[];
};

struct foo foo;m
struct foo fee[1];
struct foo fie[3];
struct foo foe[0];
struct foo fum[1];

on both compilers.  If they end up the same, then Intel needs to
change to using the 0.  If they end up different, then they are
broken relative to the C99 standard and zero length arrays a final
elements in structures.

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

Re: Question about genassym, locore.s and 0-sized arrays(showstopper for an icc compiled kernel)

[Alexander Leidinger]

On Fri, 05 Sep 2003 01:38:29 -0700
Terry Lambert <[EMAIL PROTECTED]> wrote:

> Dan Nelson wrote:
> > I guess the correct question to be asking is "does the ELF format allow
> > 0-length symbols?"
> 
> It does, according to my reading of it.  They may have an issue with
> dead code removal or element aliasing.  The way to find out would be
> to see what they emit for "[]"... 0 lenth, or 1?

% http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Question about genassym, locore.s and 0-sized arrays(showstopper for an icc compiled kernel)

[Bruce Evans]

On Thu, 4 Sep 2003, Marcel Moolenaar wrote:

> On Fri, Sep 05, 2003 at 02:59:22AM +0200, Marius Strobl wrote:
> > >
> > > We use the size of the symbol (ie the size of the object identified
> > > by the symbol) to pass around values. This we do by creating arrays.
> > > If we want to export a C constant 'FOOBAR' to assembly and the constant
> > > is defined to be 6, then we create an array for the sign, of which the
> > > size is 1 for negative numbers and 0 otherwise. In this case the array
> > > will be named FOOBARsign and its size is 0. We also create 4 arrays (*w0,
> > > *w1, *w2 and *w3), each with a maximum of 64K and corresponding to the
> > > 4 16-bit words that constitutes a single 64-bit entity.
> > > In this case
> > >   0006 C FOOBARw0
> > >    C FOOBARw1
> > >    C FOOBARw2
> > >    C FOOBARw3
> > >
> > > If the compiler creates arrays of size 1 for arrays we define as a
> > > zero-sized array, you get exactly what you've observed.
> >
> > Is this rather complex approach really necessary?
>
> In theory, yes. In practice, maybe not. If I remember correctly,
> the problem we're trying to solve is twofold:

More like fourfold:

-1: A cross-compiler must be used for the first stage.  The old method
of printf()'ing the results of sizeof(), etc., only works if the
host machine is the same as the target machine, since sizeof()
must be evaluated by a compiler for target machine and printf()
can only be run on host machines.
0:  Compiler output is to unportable to parse easily, so arrange to use
a small portable subset of it after passing it through some standard
filters.  nm output was the most portable binutils-related output
that I could think of.
> 1.  64-bit constants given the limitations of the object format,
> which included widths of 32-bit and a.out.

After choosing to use nm output, there are some minor problems representing
all relevant numbers using it.  Numbers larger than 2^32 need to be
represented but cannot be represented directly as symbol values or sizes
in nm output on 32-bit machines.  Numbers nearly as large as 2^32 can be
represented as absolute symbols, but there is no way to generate absolute
symbols in semi-portable C AFAIK.  asm() statements might work but would
be very unportable (apart from not being standard C, different ones might
be needed for the aout and elf cases).  The technique of using array sizes
for all numbers works for most sizes, but the compiler might object to
creating arrays almost as large as the address space, and as we have just
found, to creating arrays of size 0.

> 2.  Sign extension or datatype limitations in awk(1)? I'm not
> sure about this point. Bruce?

Yes: one-true-awk uses "typedef double Awkfloat;", and gawk uses something
similar by default IIRC, so awk can't hanele numbers larger than 2^53
without losing precision.  "typedef long double Awkfloat;", would be no
better because of my restriction of the precision of long doubles on
i386's and (when genassym.sh was written) the incomplete library support
for long doubles, and the nonexisted support for more than 53 bits of
precision on some supported (?) hardware.  Long doubles with 64 bits
of precision wouldn't work for representing 128-bit integers anyway.

> > ... The genassym.sh(8) of NetBSD kind
> > of directly exports the C-constants so it just needs one symbol per
> > constant and doesn't require zero sized arrays. Given that it's from
> > NetBSD their approach also should be very MI.
>
> I wouldn't have a problem using NetBSD's genassym implementation,
> provided we understand completely how it differs from ours and to
> what extend and how it affects us and provided of course we can
> live with whatever it is that's worse of just different from what
> we have now.

The main differences seem to be that it parses the assembler output.
This is less portable and not as easy -- it takes about 5 times as
much code.

If some values are unrepresentable then they need to be represtended
using other values.  E.g., add 1 to avoid 0, or multiply by the alignment
size if some element of the tool chanin instsists on rounding up things
for alignment like a broken aout version used to do.  16-bit values
would need 17 bits to represent after adding 1.

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

Re: Question about genassym, locore.s and 0-sizedarrays(showstopper for an icc compiled kernel)

[Terry Lambert]

Dan Nelson wrote:
> I guess the correct question to be asking is "does the ELF format allow
> 0-length symbols?"

It does, according to my reading of it.  They may have an issue with
dead code removal or element aliasing.  The way to find out would be
to see what they emit for "[]"... 0 lenth, or 1?


> If not, then gcc is generating invalid objects, and
> genassym will have to be rewritten to not use them (maybe add one to
> the array size, and have genassym.sh subtract it).  If it does, then
> genassym.c (sys/assym.h actually) is legal code.  If Intel doesn't want
> to change icc, we can still work around it, but there may be other code
> that will break on icc just like assym.h.

For example, an actual array of length 1 would mean you were
screwed, since treating 1 as if it were 0 would treat that as
zero, as well, and get the wrong answer.

The real answer is that the code should probably use an array
length of one, and then use the address of the array length 1
element, rather than the address of the object plus the size
of the object, when it's trying to use the zero length array
trick to glue data with the correct object alignment (according
to the array type) onto the end of a structure, which is where
most of this type of code comes from.

Unfortunately, the genassym.sh is a special case; for it to work
out if you changed the nature of the trick, the script would
need to grow special knowledge of the symbols in question.  That
is probably going to be the answer in any case, if Intel is
unwilling/unable to adopt the GCC-ism.

Anecdote on "unable":

At one point in time SEF had to deal with a compiler
issue with the Microsoft C compiler used by SCO; it
took code like this:

char *hw = "Hello World!\n" + 6;

and generated a data segment missing the "Hello ".

When the code later did this:

printf( "%s", hw - 6);

It got the wrong answer.  The problem was the MS
compiler was unable to gerate a pseudo-symbol for
the start of the data, and so had no way of taking
the origina string, and allocating storage, with a
static symbol offset +6 into the string.

If Intel ICC makes an optimization based on pruning of actually
zero-length element, or not aligning them to their type boundary,
etc., it would take deep compiler voodoo to correct this.

Hopefully, they do the right thing for "[]".

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

Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)

[Alexander Leidinger]

On Thu, 4 Sep 2003 15:57:31 -0700
Marcel Moolenaar <[EMAIL PROTECTED]> wrote:

> On Thu, Sep 04, 2003 at 05:51:23PM -0500, Dan Nelson wrote:
> > 
> > I guess the correct question to be asking is "does the ELF format allow
> > 0-length symbols?"
> 
> Of course. What size do you think a label should have otherwise?

After mentioning the difference between gcc and icc I've got this
response:
---snip---
Regarding the zero size array issue:

Objects with zero size are incomplete objects and cannot be used in any
meaningful way.  Zero length arrays are explicitly prohibited by the
Standard.  We allowed zero length arrays as a feature request.  We set
their size to one so operations involving them can make some kind of
sense.
---snip---

Can you please give me "something" a compiler developer should
understand (an URL, a reference into some standard, a description, ...)?
As long as we can provide strong evidence that gcc doesn't do the wrong
thing Intel will change icc to be compatible with gcc.

Bye,
Alexander.

-- 
Give a man a fish and you feed him for a day;
 teach him to use the Net and he won't bother you for weeks.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Question about genassym, locore.s and 0-sizedarrays(showstopper for an icc compiled kernel)

[Terry Lambert]

Alexander Leidinger wrote:
> Dan Nelson <[EMAIL PROTECTED]> wrote:
> > If you're talking FreeBSD 5, you should be able to simply subsitute a
> > C99 "flexible array member" (basically replace "[0]" with "[]") and get
> > the same effect.  0-length arrays are a gcc extension:
> >
> > http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> >
> > Under FreeBSD 4.x, you can't use them because gcc 2.95 only supports
> > the gcc extension.  Intel has added support for a lot of gcc extensions
> > recently; they may be willing to add this to the list.
> 
> Please read my mail again, icc already supports my_array[0], but the
> resulting array in the binary has size '1'. The actual showstopper is
> the output of genassym.sh. To me it seems it's just a genassym.sh issue,
> but I don't really know what's going on in the kernel, so I ask here.

The ICC is wrong.  If they are supporting a GNU extension, they
must do it the same way GNU does it, to actually be supporting
it.

The main issue here is that any reader of the object file, not
just genassym.sh, will be unable to differentiate [0] vs. [1].

What does ICC do for "[]"?  Is it '1' also, or is it '0', like
it's supposed to be?

I, for one, would not be unhappy to see the GCC-ism fade into
history.

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

Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)

[Garrett Wollman]

< said:

> In theory, yes. In practice, maybe not. If I remember correctly,
> the problem we're trying to solve is twofold:

Actually, the problem we were trying to solve is simpler than that.

genassym needs to be able to compute the values of certain constants
from header files which are only accessible to kernel code.  At the
same time, it needs to be able to run as a user process.  One
compilation unit cannot include both Standard headers like 
and kernel-specific headers like .  In fact, we muck with
the include path to ensure that Standard headers cannot be included
while compiling kernel source.

Cross-compilation does engender other issues, but that wasn't the
original motivation.

-GAWollman

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

Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)

[Marcel Moolenaar]

On Fri, Sep 05, 2003 at 02:59:22AM +0200, Marius Strobl wrote:
> > 
> > We use the size of the symbol (ie the size of the object identified
> > by the symbol) to pass around values. This we do by creating arrays.
> > If we want to export a C constant 'FOOBAR' to assembly and the constant
> > is defined to be 6, then we create an array for the sign, of which the
> > size is 1 for negative numbers and 0 otherwise. In this case the array
> > will be named FOOBARsign and its size is 0. We also create 4 arrays (*w0,
> > *w1, *w2 and *w3), each with a maximum of 64K and corresponding to the
> > 4 16-bit words that constitutes a single 64-bit entity.
> > In this case
> > 0006 C FOOBARw0
> >  C FOOBARw1
> >  C FOOBARw2
> >  C FOOBARw3
> > 
> > If the compiler creates arrays of size 1 for arrays we define as a
> > zero-sized array, you get exactly what you've observed.
> 
> Is this rather complex approach really necessary?

In theory, yes. In practice, maybe not. If I remember correctly,
the problem we're trying to solve is twofold:
1.  64-bit constants given the limitations of the object format,
which included widths of 32-bit and a.out.
2.  Sign extension or datatype limitations in awk(1)? I'm not
sure about this point. Bruce?

> ... The genassym.sh(8) of NetBSD kind
> of directly exports the C-constants so it just needs one symbol per
> constant and doesn't require zero sized arrays. Given that it's from
> NetBSD their approach also should be very MI.

I wouldn't have a problem using NetBSD's genassym implementation,
provided we understand completely how it differs from ours and to
what extend and how it affects us and provided of course we can
live with whatever it is that's worse of just different from what
we have now.

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

Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)

[Marius Strobl]

On Thu, Sep 04, 2003 at 03:47:09PM -0700, Marcel Moolenaar wrote:
> 
> We use the size of the symbol (ie the size of the object identified
> by the symbol) to pass around values. This we do by creating arrays.
> If we want to export a C constant 'FOOBAR' to assembly and the constant
> is defined to be 6, then we create an array for the sign, of which the
> size is 1 for negative numbers and 0 otherwise. In this case the array
> will be named FOOBARsign and its size is 0. We also create 4 arrays (*w0,
> *w1, *w2 and *w3), each with a maximum of 64K and corresponding to the
> 4 16-bit words that constitutes a single 64-bit entity.
> In this case
>   0006 C FOOBARw0
>    C FOOBARw1
>    C FOOBARw2
>    C FOOBARw3
> 
> If the compiler creates arrays of size 1 for arrays we define as a
> zero-sized array, you get exactly what you've observed.
> 

Is this rather complex approach really necessary? I have successfully
generated assyms.s' using genassym.sh(8) from NetBSD and both ICC and
GCC on i386 which have exactly the same values as one generated with
sys/kern/genassym.sh from FreeBSD. The genassym.sh(8) of NetBSD kind
of directly exports the C-constants so it just needs one symbol per
constant and doesn't require zero sized arrays. Given that it's from
NetBSD their approach also should be very MI.

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

Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)

[Marcel Moolenaar]

On Thu, Sep 04, 2003 at 05:51:23PM -0500, Dan Nelson wrote:
> 
> I guess the correct question to be asking is "does the ELF format allow
> 0-length symbols?"

Of course. What size do you think a label should have otherwise?

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

Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)

[Dan Nelson]

In the last episode (Sep 05), Alexander Leidinger said:
> On Thu, 4 Sep 2003 11:28:58 -0500
> Dan Nelson <[EMAIL PROTECTED]> wrote:
> > If you're talking FreeBSD 5, you should be able to simply subsitute
> > a C99 "flexible array member" (basically replace "[0]" with "[]")
> > and get the same effect.  0-length arrays are a gcc extension:
> > 
> > http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> > 
> > Under FreeBSD 4.x, you can't use them because gcc 2.95 only
> > supports the gcc extension.  Intel has added support for a lot of
> > gcc extensions recently; they may be willing to add this to the
> > list.
> 
> Please read my mail again, icc already supports my_array[0], but the
> resulting array in the binary has size '1'. The actual showstopper is
> the output of genassym.sh. To me it seems it's just a genassym.sh
> issue, but I don't really know what's going on in the kernel, so I
> ask here.

Ok, I reread the original message, and it's still a zero-length array
problem, but in a different place.

What it looks like to me is that icc silently converts zero-length
arrays to 1 element when creating the assembly output.  While it's
processing C source, sizeof(my_array) returns 0, but the emitted
assembly says otherwise:

$ cat > test.c
int test0[0];
int test1[1];
int test2[2];
^D
$ gcc -c test.c -S -o test.gcc
$ icc -c test.c -S -o test.icc
$ grep comm test.?cc
test.gcc:   .comm   test0,0,4
test.gcc:   .comm   test1,4,4
test.gcc:   .comm   test2,8,4
test.icc:   .comm test2,8,4
test.icc:   .comm test1,4,4
test.icc:   .comm test0,4,4

So gcc emitted symbols with the same size as in the source file, with
an alignment of 4 bytes (since I'm using ints in this example), but icc
adjusted the test0 symbol to be one int long.  I used ints to make it
more obvious what icc is doing; the effect is the same if you use
chars.

I guess the correct question to be asking is "does the ELF format allow
0-length symbols?"  If not, then gcc is generating invalid objects, and
genassym will have to be rewritten to not use them (maybe add one to
the array size, and have genassym.sh subtract it).  If it does, then
genassym.c (sys/assym.h actually) is legal code.  If Intel doesn't want
to change icc, we can still work around it, but there may be other code
that will break on icc just like assym.h.

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

Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)

[Marcel Moolenaar]

On Fri, Sep 05, 2003 at 12:14:11AM +0200, Alexander Leidinger wrote:
> On Thu, 4 Sep 2003 11:28:58 -0500
> Dan Nelson <[EMAIL PROTECTED]> wrote:
> 
> > If you're talking FreeBSD 5, you should be able to simply subsitute a
> > C99 "flexible array member" (basically replace "[0]" with "[]") and get
> > the same effect.  0-length arrays are a gcc extension:
> > 
> > http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> > 
> > Under FreeBSD 4.x, you can't use them because gcc 2.95 only supports
> > the gcc extension.  Intel has added support for a lot of gcc extensions
> > recently; they may be willing to add this to the list.
> 
> Please read my mail again, icc already supports my_array[0], but the
> resulting array in the binary has size '1'. The actual showstopper is
> the output of genassym.sh. To me it seems it's just a genassym.sh issue,
> but I don't really know what's going on in the kernel, so I ask here.

We use the size of the symbol (ie the size of the object identified
by the symbol) to pass around values. This we do by creating arrays.
If we want to export a C constant 'FOOBAR' to assembly and the constant
is defined to be 6, then we create an array for the sign, of which the
size is 1 for negative numbers and 0 otherwise. In this case the array
will be named FOOBARsign and its size is 0. We also create 4 arrays (*w0,
*w1, *w2 and *w3), each with a maximum of 64K and corresponding to the
4 16-bit words that constitutes a single 64-bit entity.
In this case
0006 C FOOBARw0
 C FOOBARw1
 C FOOBARw2
 C FOOBARw3

If the compiler creates arrays of size 1 for arrays we define as a
zero-sized array, you get exactly what you've observed.

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

Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)

[Alexander Leidinger]

On Thu, 4 Sep 2003 11:28:58 -0500
Dan Nelson <[EMAIL PROTECTED]> wrote:

> If you're talking FreeBSD 5, you should be able to simply subsitute a
> C99 "flexible array member" (basically replace "[0]" with "[]") and get
> the same effect.  0-length arrays are a gcc extension:
> 
> http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> 
> Under FreeBSD 4.x, you can't use them because gcc 2.95 only supports
> the gcc extension.  Intel has added support for a lot of gcc extensions
> recently; they may be willing to add this to the list.

Please read my mail again, icc already supports my_array[0], but the
resulting array in the binary has size '1'. The actual showstopper is
the output of genassym.sh. To me it seems it's just a genassym.sh issue,
but I don't really know what's going on in the kernel, so I ask here.

Bye,
Alexander.

-- 
  Weird enough for government work.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)

[Dan Nelson]

In the last episode (Sep 04), Alexander Leidinger said:
> At the moment I discussing an issue with Intel regarding 0-sized
> arrays. gcc seems to be violating the standard and produces code with
> an array size of "0", whereas icc produces code where an 0-sized
> array has the size "1". This results in different nm output of
> genassym.o:
[snip] 
>  - If we depend on it: how hard would it be to rewrite it to not depend
>on 0-sized arrays (and does someone volunteer to rewrite it)? It
>would be nice if someone could point me to the source if it isn't
>an easy task, my contact @Intel is willing to convince the
>developers to change icc, but he has to "present a persuasive
>argument to development to pursue a solution".

If you're talking FreeBSD 5, you should be able to simply subsitute a
C99 "flexible array member" (basically replace "[0]" with "[]") and get
the same effect.  0-length arrays are a gcc extension:

http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html

Under FreeBSD 4.x, you can't use them because gcc 2.95 only supports
the gcc extension.  Intel has added support for a lot of gcc extensions
recently; they may be willing to add this to the list.

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

Re: Question related to FreeBSD Serial Console...

[Matthew D. Fuller]

On Tue, Sep 02, 2003 at 12:18:51PM +0100 I heard the voice of
[EMAIL PROTECTED], and lo! it spake thus:
> 
> Keyboard and mouse manufacturers usually give dire warnings about plugging
> in PS/2 devices when the machine is powered up, maybe that's the reason
> why.

I think it's more because the interface isn't really designed
electrically to support hot-plugging.  I've cooked motherboards[0] by
hot-plugging keyboards before.

[0] Often I could, after heating up the soldering iron and a trip to
Radio Shack, recover them, but not always.



-- 
Matthew Fuller (MF4839)   |  [EMAIL PROTECTED]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/

"The only reason I'm burning my candle at both ends, is because I
  haven't figured out how to light the middle yet"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Question related to FreeBSD Serial Console...

[Bruce M Simpson]

On Mon, Sep 01, 2003 at 05:29:09PM -0600, Scott Long wrote:
> At one time I was working on patches to the loader to make the console
> speed configurable.  At the time, at least, I didn't see any evidence
> that the settings were stored in the boot0 block, but maybe I was wrong.
> In any case, finishing this up is on my TODO list.

I was trying to make the boot process 100% independent of the VGA console
at one stage.  To the best of my knowledge, boot0 doesn't know anything
about serial, unless someone's using my boot0sio hack (which I haven't
committed, btw; it was very specific - you have only 512 bytes to play
with in the MBR, and I understand people had problems with jhb's 1024 byte
boot0).

boot2 is probably the more interesting part, it does make assumptions
if BOOT_COMCONSOLE_SPEED wasn't specified in the make, and loader takes its
cue from that up until it sees 'console' in loader.conf[.local].

One of the limitations here is that there can only be one console. Anything
else would be something of a hack to get boot2 and loader to tee their
output to two independent devices.

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

Re: Question related to FreeBSD Serial Console...

[Scott M. Likens]

On Tue, 2003-09-02 at 01:33, Bruce Evans wrote:
> About the original question: multiple consoles in the kernel are
> unsupported in FreeBSD-4 but are standard in -current.  Unfortunately,
> their implementation is slightly incomplete even in -current.  In
> -current, you get them by booting with -D after booting using the
> kern.console sysctl.  The number of consoles is limited only by the
> number of devices that support consoles.  Low level console i/o (mainly
> boot messages and other kernel messags printed by kernel printfs) is
> then sent to and received from all the consoles, but for some reason
> high-level console output (all i/o from/to /dev/console) is only sent
> to the first console in the list.  This should be easy to fix for
> writes and ioctls though not so easy for reads.  I think booting with
> -Dh makes the serial console first and booting with -D makes the video
> console first (if both are configured).  The order can be changed using
> the sysctl.

Eh veh, 10 different answers to 1 question.  The mailing list is doing
it's job.  But okay, yes I was wanting both consoles to be initialized
at the same exact time really.  

So I would guess then, -current would be best supported for this.  That
or find a motherboard with builtin serial console support.

What a solution, was hoping for something more of an easy answer.  But
Thanks!


> On Mon, 1 Sep 2003, Scott Long wrote:
> 
> > John Birrell wrote:
> > > On Mon, Sep 01, 2003 at 05:29:09PM -0600, Scott Long wrote:
> > >
> > >>At one time I was working on patches to the loader to make the console
> > >>speed configurable.  At the time, at least, I didn't see any evidence
> > >>that the settings were stored in the boot0 block, but maybe I was wrong.
> 
> There are already too many places to set it.
> 
> > > AFAIK, the boot0 block uses bios int 0x16 to get a key-press and bios int
> > > 0x10 to display a character, so in a situation where you *want* a serial
> > > console, the F1 etc stuff can't be used unless the bios supports console
> > > re-direction. And you have to live with whatever baud rate the bios sets.
> 
> I think boot0 is already full (unless you unportabalize it by expanding it
> beyond one sector).  It doesn't have its own serial i/o routines mainly
> because there is no space for them.
> 
> > > Once you get to boot2, then the serial console can work if set in /boot.config.
> > >
> > > It would be nice to have a boot.config setting for the baud rate. I have a
> > > board here that allows bios re-direction to either the first or second serial
> > > port at a fixed baud rate of 38400. I have to build boot2 with
> > > BOOT_COMCONSOLE_SPEED=38400, and then the kernel with CONSPEED=38400 to
> > > get all the ducks in a row.
> 
> The latter shouldn't be necessary.  The kernel (i386 sio only) uses the
> same speed that boot2 used if the kernel was booted with -h.  It should
> also use the same speed if the kernel was booted with -D.
> 
> > > But it would be even nicer if both boot2 and the kernel would just work with
> > > whatever baud rate the bios set.
> >
> > This is exactly the problem that I was working on.
> 
> Unfortunately most BIOSes don't provide a way to set the speed.  I'm not
> sure that it even has a default.  I always use 115200 bps, but at least he
> old BIOS interface is limited to 9600 bps.  I may work on this a bit soon
> to make 921600 bps work.
> 
> Bruce
-- 
"I think we ought to be out there doing what we do best - making large
holes in other people's countries." - George Carlin



signature.asc
Description: This is a digitally signed message part
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"