Re: Switchover to CAM ATA?

[Andriy Gapon]

on 23/04/2010 07:48 Szilveszter Adam said the following:
> There is one interesting tidbit though: previously it used to be
> possible to run cdda2wav also as non-root, provided the user running it
> had read access to the /dev/cd0 device. This seems to no longer work.

Probably you also need access to the corresponding passX device, which you can
find from output of 'camcontrol devlist'.
You didn't need that with *a*cd0.

-- 
Andriy Gapon
___
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: Switchover to CAM ATA?

[Matthew D. Fuller]

On Fri, Apr 23, 2010 at 06:48:09AM +0200 I heard the voice of
Szilveszter Adam, and lo! it spake thus:
> 
> There is one interesting tidbit though: previously it used to be
> possible to run cdda2wav also as non-root, provided the user running it
> had read access to the /dev/cd0 device. This seems to no longer work.
> 
> Has anybody else noticed this?

I think you may need to use the /dev/xpt* or /dev/pass* perms.  Can't
remember which.


-- 
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: Switchover to CAM ATA?

[Joel Dahl]

On 22-04-2010 18:31, Alexander Motin wrote:
> Hi.
> 
> With time passed, CAM-based ATA infrastructure IMHO looks enough mature
> now to enable it in HEAD. Now we have two new stable drivers ahci(4) and
> siis(4), covering major part of modern SATA HBAs, `options ATA_CAM`
> wrapper for ata(4) to supports legacy hardware, and one more improved
> driver for Marvell HBAs (mvs) is now in development and soon will be
> present for testing. Together with many other people I have tested above
> at least on i386, amd64, arm and spart64 architectures.

If we want this in 9.0 we should probably switch to CAM ATA in HEAD now in
order to allow enough testing before the release.

--
Joel
___
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: Switchover to CAM ATA?

[Nenhum_de_Nos]

On Thu, 22 Apr 2010 22:28:03 +0400
Lev Serebryakov  wrote:

> Hello, Alexander.
> You wrote 22 апреля 2010 г., 19:31:37:
> 
> > and RAID5 (due to lack of module in a base system).
>  I'm  cleaning  up  gradi5  now according to style(9) and want to make
> port  out of it in month or two ("unfortunalety", I have  alot of paid
> work, which is not FreeBSD-related in any way).
>  It  works  very  well  for  me  on, and I have one HDD crash already,
> recovered with graid5 :)

this means graid5 in the tree ?

if so, great :)

never seen how to make simple raid5 in not-so-great memory systems tht can't 
afford to have zfs. I have a Pentium II with 192MB ram that is a great small 
file server and runs both gmirror and gstripe fine.

thanks,

matheus

-- 
We will call you cygnus,
The God of balance you shall be

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

http://en.wikipedia.org/wiki/Posting_style
___
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: Switchover to CAM ATA?

[Szilveszter Adam]

Dear Alexander, dear collegaues,

On Thu, Apr 22, 2010 at 06:31:37PM +0300, Alexander Motin wrote:
> Can we do switchover now, or some more reasons preventing this?

I have been using ATA_CAM with legacy support for ata(4) for some time,
and have found it to be stable and very useable. I have even removed
atapicam from the kernel, since it is no longer needed, I have the
/dev/cd0 device also without. So, in my opinion it is ready for
prime-time also on legacy hw.

There is one interesting tidbit though: previously it used to be
possible to run cdda2wav also as non-root, provided the user running it
had read access to the /dev/cd0 device. This seems to no longer work.

Has anybody else noticed this?

-- 
Regards:

Szilveszter ADAM
Budapest
Hungary
___
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: [CFT]: ClangBSD is selfhosting, we need testers now

[Brooks Davis]

On Thu, Apr 22, 2010 at 04:32:45PM -0700, K. Macy wrote:
> The current llvm-devel package is woefully out of date. Anyone wishing
> to try this will need to compile the latest port.

For the foreseeable future, doing anything but using the latest port is a
recipe for problems.

-- Brooks

> -Kip
> 
> 
> On Fri, Apr 16, 2010 at 9:08 AM, Roman Divacky  wrote:
> > Hi,
> >
> > ClangBSD is a branch of FreeBSD that aims at integrating clang 
> > (clang.llvm.org)
> > into FreeBSD, replacing GCC as a system compiler.
> >
> > Recently, we've achieved the state when clang can compile all of FreeBSD 
> > world
> > on i386/amd64 platforms (including all the C++ apps we have and itself)
> > and a bootable kernel. Thus we feel that the time has come to ask the 
> > FreeBSD
> > community for wider testing on i386/amd64 (you sure can help with other
> > platforms too :)).
> >
> > How to setup ClangBSD:
> >
> > The default configuration of ClangBSD requires clang installed so you can
> > either install fresh llvm-devel port (portinstall devel/llvm-devel) or 
> > change
> > CC to "gcc" and CXX to "g++" in share/mk/sys.mk. I recommend the former.
> >
> >
> > ? ? ? ?svn co http://svn.freebsd.org/base/projects/clangbsd/ clangbsd
> >
> > ? ? ? ?cd clangbsd && make buildworld
> >
> > ? ? ? ?echo NO_WERROR= >> /etc/make.conf
> > ? ? ? ?echo WERROR= ? ?>> /etc/make.conf
> >
> > ? ? ? ?make DESTDIR=/clangbsd-chroot/ installworld
> >
> >
> > now you have ClangBSD world installed and you can chroot into it. I don't
> > recommend installing ClangBSD into real root as it is not tested enough.
> >
> > You can also start using clang compiled kernel - either build the kernel in
> > the ClangBSD chroot (set NO_WERROR=yo and WERROR=yo in /etc/src.conf) or set
> > CC to clang and build kernel the normal way.
> >
> > This information (and more) is also provided on:
> >
> > ? ? ? ?http://wiki.freebsd.org/BuildingFreeBSDWithClang
> >
> > We kindly ask you to setup ClangBSD chroot and/or use clang compiled kernel 
> > and
> > use it as you would normally use FreeBSD. Please report back
> >
> > Thank you,
> >
> > ? Roman Divacky on behalf of the ClangBSD team
> >
> ___
> 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"
> 


pgpwhrrk7fQph.pgp
Description: PGP signature

Re: MCA messages in /var/log/message?

[Steve Kargl]

On Fri, Apr 23, 2010 at 02:24:03AM +0300, Andriy Gapon wrote:
> on 23/04/2010 01:28 Steve Kargl said the following:
> > How does one interpret the following MCA message?
> > 
> > MCA: Bank 4, Status 0x945a4000d6080a13
> > MCA: Global Cap 0x0105, Status 0x
> > MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0
> > MCA: CPU 0 COR BUSLG Responder RD Memory
> > MCA: Address 0x70c42280
> > MCA: Bank 4, Status 0x942140012a080813
> > MCA: Global Cap 0x0105, Status 0x
> > MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 1
> > MCA: CPU 1 COR BUSLG Source RD Memory
> > MCA: Address 0x1b97ca578
> > 
> > It appears that these messages coincide with a 15 to 30
> > second period where my USB mouse inexplicably loses a
> > large number of button clicks, (which is quite noticable
> > with firefox3).
> 
> This very much looks like DRAM ECC error.
> You seem to have family Fh AMD processor, so I am not entirely sure.
> But for 10h processors BKDG table 80 (NB error signatures) definitely 
> specifies
> that extended error code of 8 (in bits 20:16) means ECC error.
> 

Thanks for the information.  The system that generates these
messages is getting long in the tooth.  Guess it's time to
reboot and run memtest86+ on the system.

-- 
Steve
___
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: [CFT]: ClangBSD is selfhosting, we need testers now

[K. Macy]

The current llvm-devel package is woefully out of date. Anyone wishing
to try this will need to compile the latest port.

-Kip


On Fri, Apr 16, 2010 at 9:08 AM, Roman Divacky  wrote:
> Hi,
>
> ClangBSD is a branch of FreeBSD that aims at integrating clang 
> (clang.llvm.org)
> into FreeBSD, replacing GCC as a system compiler.
>
> Recently, we've achieved the state when clang can compile all of FreeBSD world
> on i386/amd64 platforms (including all the C++ apps we have and itself)
> and a bootable kernel. Thus we feel that the time has come to ask the FreeBSD
> community for wider testing on i386/amd64 (you sure can help with other
> platforms too :)).
>
> How to setup ClangBSD:
>
> The default configuration of ClangBSD requires clang installed so you can
> either install fresh llvm-devel port (portinstall devel/llvm-devel) or change
> CC to "gcc" and CXX to "g++" in share/mk/sys.mk. I recommend the former.
>
>
>        svn co http://svn.freebsd.org/base/projects/clangbsd/ clangbsd
>
>        cd clangbsd && make buildworld
>
>        echo NO_WERROR= >> /etc/make.conf
>        echo WERROR=    >> /etc/make.conf
>
>        make DESTDIR=/clangbsd-chroot/ installworld
>
>
> now you have ClangBSD world installed and you can chroot into it. I don't
> recommend installing ClangBSD into real root as it is not tested enough.
>
> You can also start using clang compiled kernel - either build the kernel in
> the ClangBSD chroot (set NO_WERROR=yo and WERROR=yo in /etc/src.conf) or set
> CC to clang and build kernel the normal way.
>
> This information (and more) is also provided on:
>
>        http://wiki.freebsd.org/BuildingFreeBSDWithClang
>
> We kindly ask you to setup ClangBSD chroot and/or use clang compiled kernel 
> and
> use it as you would normally use FreeBSD. Please report back
>
> Thank you,
>
>   Roman Divacky on behalf of the ClangBSD team
>
___
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: MCA messages in /var/log/message?

[Andriy Gapon]

on 23/04/2010 01:28 Steve Kargl said the following:
> How does one interpret the following MCA message?
> 
> MCA: Bank 4, Status 0x945a4000d6080a13
> MCA: Global Cap 0x0105, Status 0x
> MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0
> MCA: CPU 0 COR BUSLG Responder RD Memory
> MCA: Address 0x70c42280
> MCA: Bank 4, Status 0x942140012a080813
> MCA: Global Cap 0x0105, Status 0x
> MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 1
> MCA: CPU 1 COR BUSLG Source RD Memory
> MCA: Address 0x1b97ca578
> 
> It appears that these messages coincide with a 15 to 30
> second period where my USB mouse inexplicably loses a
> large number of button clicks, (which is quite noticable
> with firefox3).

This very much looks like DRAM ECC error.
You seem to have family Fh AMD processor, so I am not entirely sure.
But for 10h processors BKDG table 80 (NB error signatures) definitely specifies
that extended error code of 8 (in bits 20:16) means ECC error.


-- 
Andriy Gapon
___
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"

MCA messages in /var/log/message?

[Steve Kargl]

How does one interpret the following MCA message?

MCA: Bank 4, Status 0x945a4000d6080a13
MCA: Global Cap 0x0105, Status 0x
MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0
MCA: CPU 0 COR BUSLG Responder RD Memory
MCA: Address 0x70c42280
MCA: Bank 4, Status 0x942140012a080813
MCA: Global Cap 0x0105, Status 0x
MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 1
MCA: CPU 1 COR BUSLG Source RD Memory
MCA: Address 0x1b97ca578

It appears that these messages coincide with a 15 to 30
second period where my USB mouse inexplicably loses a
large number of button clicks, (which is quite noticable
with firefox3).

-- 
Steve
___
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: Switchover to CAM ATA?

[Maxim Sobolev]

Richard Tector wrote:

On 22/04/2010 19:48, Maxim Sobolev wrote:

Alexander Motin wrote:

So what is the public opinion: Is the lack of ataraid(4) fatal or we can
live without it?


I believe it's fatal in long run. This would present significant 
challenge for users who rely on this functionality from upgrading from 
8.x to 9.0 later on. Especially for ones using striped disks and RAID5.


Therefore while it's no problem to have it in HEAD for now, but it 
will have to be addressed before the release.


Could I also add that the removal of ataraid would affect those users 
who dual-boot with Windows and rely on the psuedo-raid provided by most 
Intel chipsets to be able to share the same pair of disks.


Well, this won't be a problem if we have GEOM classes that can 
understand metadata created by the ATA RAID BIOS(es). But we don't those 
classes at the moment.


-Maxim
___
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: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

[Maxim Sobolev]

John Baldwin wrote:

On Thursday 22 April 2010 2:28:26 pm Maxim Sobolev wrote:

John Baldwin wrote:

On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote:

Maxim Sobolev wrote:
There is already a code to detect non-existing AT keyboard and avoid 
attaching atkbd to it. The code is i386-only at the moment, I am trying 
to figure out how to modify it so that it works on amd64 as well.
Looks like this huge delay is caused by the inb() being astonishingly 
slow, which is not factored by the timeout routines. Reading keyboard 
status port once takes about 0.003s! I am not sure if it's common 
behaviour of the platform, or something specific to this particular 
model. Do you know by any chance?
Well, many BIOSes trigger an SMI# when doing inb/outb to the keyboard ports so 
they can emulate a PS/2 keyboard when a USB keyboard is inserted.  Do you have 
any BIOS options related to the USB legacy compat?  I know of the Nehalem 
systems I've seen they have a separate option for controlling port 60/64 
emulation which we leave disabled by default.
That makes sense. Unfortunately I don't have access to the BIOS 
settings. This is a hosted system, and the provider keeps BIOS password 
for themselves.


I have a patch that fixes that issue by measuring status register 
reading time first and then factoring it in the calculations of the 
number of retries:


http://sobomax.sippysoft.com/atkbdc.diff

It also applies the same logic to detect broken/non-existing keyboard 
controller to amd64 as we do to the i386. I'd appreciate if you can do a 
review.


Hmm, not all i386 CPUs that we support have a TSC.  Is the change to
atkbdc_isa.c sufficient to fix the hang?  If so, I'd rather just commit that
bit and leave out the read_delay changes.


No, it's not sufficient. The problem here is that for some reason that 
test passes on that system (probably emulation works) and so that normal 
keyboard attach routine is invoked early in boot, when we don't even 
have clock initialized. What if I make TSC-related changes amd64? Will 
that be OK?


-Maxim
___
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: Switchover to CAM ATA?

[Richard Tector]

On 22/04/2010 19:48, Maxim Sobolev wrote:

Alexander Motin wrote:

So what is the public opinion: Is the lack of ataraid(4) fatal or we can
live without it?


I believe it's fatal in long run. This would present significant 
challenge for users who rely on this functionality from upgrading from 
8.x to 9.0 later on. Especially for ones using striped disks and RAID5.


Therefore while it's no problem to have it in HEAD for now, but it 
will have to be addressed before the release.


Could I also add that the removal of ataraid would affect those users 
who dual-boot with Windows and rely on the psuedo-raid provided by most 
Intel chipsets to be able to share the same pair of disks.


Regards,

Richard
___
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: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

[John Baldwin]

On Thursday 22 April 2010 2:28:26 pm Maxim Sobolev wrote:
> John Baldwin wrote:
> > On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote:
> >> Maxim Sobolev wrote:
> >>> There is already a code to detect non-existing AT keyboard and avoid 
> >>> attaching atkbd to it. The code is i386-only at the moment, I am trying 
> >>> to figure out how to modify it so that it works on amd64 as well.
> >> Looks like this huge delay is caused by the inb() being astonishingly 
> >> slow, which is not factored by the timeout routines. Reading keyboard 
> >> status port once takes about 0.003s! I am not sure if it's common 
> >> behaviour of the platform, or something specific to this particular 
> >> model. Do you know by any chance?
> > 
> > Well, many BIOSes trigger an SMI# when doing inb/outb to the keyboard ports 
> > so 
> > they can emulate a PS/2 keyboard when a USB keyboard is inserted.  Do you 
> > have 
> > any BIOS options related to the USB legacy compat?  I know of the Nehalem 
> > systems I've seen they have a separate option for controlling port 60/64 
> > emulation which we leave disabled by default.
> 
> That makes sense. Unfortunately I don't have access to the BIOS 
> settings. This is a hosted system, and the provider keeps BIOS password 
> for themselves.
> 
> I have a patch that fixes that issue by measuring status register 
> reading time first and then factoring it in the calculations of the 
> number of retries:
> 
> http://sobomax.sippysoft.com/atkbdc.diff
> 
> It also applies the same logic to detect broken/non-existing keyboard 
> controller to amd64 as we do to the i386. I'd appreciate if you can do a 
> review.

Hmm, not all i386 CPUs that we support have a TSC.  Is the change to
atkbdc_isa.c sufficient to fix the hang?  If so, I'd rather just commit that
bit and leave out the read_delay changes.

-- 
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: [CFT]: ClangBSD is selfhosting, we need testers now

[Alexander Best]

Ulrich Spörlein schrieb am 2010-04-22:
> On Wed, 21.04.2010 at 23:30:15 +0200, Alexander Best wrote:
> > Roman Divacky schrieb am 2010-04-21:
> > > On Wed, Apr 21, 2010 at 09:44:45PM +0200, Alexander Best wrote:
> > > > Roman Divacky schrieb am 2010-04-21:

> > > > [snip]

> > > > > 1) cd modules/sound/sound && make CC=gcc

> > > > after this step these are the sizes of sound.ko* in
> > > > modules/sound/sound:

> > > > -rw-r--r--  1 root  wheel   449120 Apr 21 21:36 sound.ko
> > > > -rw-r--r--  1 root  wheel  2284757 Apr 21 21:36 sound.ko.debug
> > > > -rw-r--r--  1 root  wheel  2055512 Apr 21 21:36
> > > > sound.ko.symbols

> > > > > 2) make -V SRCS | tr " " "\n" | grep -v \.h | sort | grep
> > > > >"^[a-m].*"
> > > > >| xargs touch

> > > this line is wrong.. it creates empty files which are used
> > > instead
> > > of touching the existing ones...  it needs to be adjusted so it
> > > touches the files (thus forcing them to be rebuilt with the
> > > second
> > > make invocation)

> > i'm now 100% sure that buffer.c is causing the problem. what i did
> > to verify
> > this was:

> > cd sys/modules/sound/sound && make CC=clang && touch
> > ../../../dev/sound/pcm/buffer.c && make CC=gcc && make install

> > this gives me working sound!

> Great stuff to have narrowed it down so much. Next logical step would
> be
> to do the bisect on function-level scope.

> Copy one half of buffer.c to buffer-clang.c, the other half to
> buffer-gcc.c,
> adjust the Makefile to use buffer-{gcc,clang}.c instead of buffer.c
> and
> compile them accordingly. Redo your tests till we know the single
> function(s)
> where clang produces bad code.

thanks for the hint. i'll try and see if i can pinpoint the exact function in
buffer.c causing the problem.

> Hang in there, the hard part is almost done!
> Uli

-- 
Alexander Best
___
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: [CFT]: ClangBSD is selfhosting, we need testers now

[Alexander Best]

Andrew Reilly schrieb am 2010-04-22:
> On Wed, Apr 21, 2010 at 05:23:38PM +0200, Roman Divacky wrote:
> > On Wed, Apr 21, 2010 at 05:20:57PM +0200, Alexander Best wrote:
> > > i might have stumbled upon a problem with clang. i've compiled a
> > > kernel from
> > > the clang branch using `make kernel INSTKERNNAME=clang` and
> > > booted from it.
> > > i'm now experiencing audio problems with mp3s and certain video
> > > files.
> > > playback is awfully slow and the audio output gets distorted
> > > massively. `top`
> > > however reports no high cpu load and `vmstat -i` doesn't report
> > > anything
> > > unusual either.

> > > this problem doesn't occur with a regular gcc-kernel.

> > > both kernels are running under a regular (gcc) world.

> > > i thought it might be a problem with acpi, but disabling acpi
> > > (hint.acpi.0.disabled=1) gives me a system freeze.

> > I've heard about this problem but did not manage to reproduce that.

> > can you try to bisect what file is being miscompiled? ie. compile
> > half of the kernel with gcc and half with clang and bisect this
> > way to a single file.

> The FreeBSD sound subsystem has a sample-rate converter built
> into the feeder that (from a cursory look) is probably quite
> carefully tweaked to be able to perform well (or at all).  I've
> added -multimedia to the CC line, because they're the guys
> who are going to know the details.  It's possible that some
> GCC-specific manifest constants are being tested-for, with
> sub-optimal fall-back code being run, instead.

> In the mean-time, Alexander, are there any sound-related sysctls
> that you can tweak so that the audio playback that you're doing
> does *not* involve sample rate conversion?

i'm not sure because i'm not an expert on audio stuff. these sysctl vars might
contain the functionality you mentioned:

hw.snd.feeder_rate_presets: 100:8:0.85 100:36:0.92 100:164:0.97
hw.snd.feeder_rate_polyphase_max: 183040
hw.snd.feeder_rate_min: 1
hw.snd.feeder_rate_max: 2016000
hw.snd.feeder_rate_round: 25
hw.snd.feeder_rate_quality: 1
hw.snd.feeder_eq_presets:
PEQ:16000,0.2500,62,0.2500:-9,9,1.0:44100,48000,88200,96000,176400,192000
hw.snd.feeder_eq_exact_rate: 0


> Cheers,


-- 
Alexander Best
___
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: Switchover to CAM ATA?

[Maxim Sobolev]

Alexander Motin wrote:

So what is the public opinion: Is the lack of ataraid(4) fatal or we can
live without it?


I believe it's fatal in long run. This would present significant 
challenge for users who rely on this functionality from upgrading from 
8.x to 9.0 later on. Especially for ones using striped disks and RAID5.


Therefore while it's no problem to have it in HEAD for now, but it will 
have to be addressed before the release.


-Maxim
___
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: Switchover to CAM ATA?

[Lev Serebryakov]

Hello, Alexander.
You wrote 22 апреля 2010 г., 19:31:37:

> and RAID5 (due to lack of module in a base system).
 I'm  cleaning  up  gradi5  now according to style(9) and want to make
port  out of it in month or two ("unfortunalety", I have  alot of paid
work, which is not FreeBSD-related in any way).
 It  works  very  well  for  me  on, and I have one HDD crash already,
recovered with graid5 :)

-- 
// Black Lion AKA Lev Serebryakov 

___
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: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

[Maxim Sobolev]

John Baldwin wrote:

On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote:

Maxim Sobolev wrote:
There is already a code to detect non-existing AT keyboard and avoid 
attaching atkbd to it. The code is i386-only at the moment, I am trying 
to figure out how to modify it so that it works on amd64 as well.
Looks like this huge delay is caused by the inb() being astonishingly 
slow, which is not factored by the timeout routines. Reading keyboard 
status port once takes about 0.003s! I am not sure if it's common 
behaviour of the platform, or something specific to this particular 
model. Do you know by any chance?


Well, many BIOSes trigger an SMI# when doing inb/outb to the keyboard ports so 
they can emulate a PS/2 keyboard when a USB keyboard is inserted.  Do you have 
any BIOS options related to the USB legacy compat?  I know of the Nehalem 
systems I've seen they have a separate option for controlling port 60/64 
emulation which we leave disabled by default.


That makes sense. Unfortunately I don't have access to the BIOS 
settings. This is a hosted system, and the provider keeps BIOS password 
for themselves.


I have a patch that fixes that issue by measuring status register 
reading time first and then factoring it in the calculations of the 
number of retries:


http://sobomax.sippysoft.com/atkbdc.diff

It also applies the same logic to detect broken/non-existing keyboard 
controller to amd64 as we do to the i386. I'd appreciate if you can do a 
review.


-Maxim
___
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: newsyslog patch implementing file includes

[Gordon Tetlow]

On Thu, Apr 22, 2010 at 6:26 AM, John Baldwin  wrote:

> This is a great feature!  One suggestion, I think this text in the new
> manpage
> isn't quite right:
>
>  Name of the system log file to be archived, the literal string "default",
>  or "include".
>
> I think it's ambiguous about "include" also being a literal string.  Two
> possible suggestions:
>
>  Name of the system log file to be archived, or one of the literal strings
>  "default" or "include".
>
>  Name of the system log file to be archived, the literal string "default",
>  or the literal string "include".
>

I took your first suggestion and updated the patch.

Thanks,
Gordon
___
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: Re: Switchover to CAM ATA?

[Andrey V . Elsukov]

22.04.10, 11:17, "Adam Vande More":

>  I think sade(and by further discussion sysinstall) is now getting some
>  attention and now supports geom devices, zfs, etc at least in one person's
>  testbed.  I know that's it's been tried before but there are actually
>  screenshots from it.
>  
>  http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016418.html

Yes, I have plans to add support of simple GEOM-based RAID management
in sade.

-- 
WBR, Andrey V. Elsukov
___
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: Switchover to CAM ATA?

[Matthew Jacob]

Short opinion from me: Yes, for HEAD. Not MFC'able. It's too major a 
change for that.

___
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: Switchover to CAM ATA?

[Adam Vande More]

On Thu, Apr 22, 2010 at 11:25 AM, Julian Elischer wrote:

> just one little fly in that ointment...  booting.
>
> You need to be able to act with the raid in the same way the bios does
> or you can't boot. I don't think geom would easlily do that but I could be
> wrong. Certainly if you treat teh ata raid as just a bunch of striped disks,
> then the bios will not be able to boot off it.
>
> of course don't take my word too seriosly asn I'm not running an ata raid
> system at the moment.
>

gmirror booting works great only thing to change is fstab to reflect block
dev changes, gstripe doesn't.  I honestly wasn't aware ataraid could boot a
striped volume, if so it does something geom can't.


-- 
Adam Vande More
___
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: Switchover to CAM ATA?

[Julian Elischer]

On 4/22/10 9:17 AM, Adam Vande More wrote:






+1 on ataraid's retirement.


just one little fly in that ointment...  booting.

You need to be able to act with the raid in the same way the bios does
or you can't boot. I don't think geom would easlily do that but I 
could be wrong. Certainly if you treat teh ata raid as just a bunch of 
striped disks, then the bios will not be able to boot off it.


of course don't take my word too seriosly asn I'm not running an ata 
raid system at the moment.



___
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: Switchover to CAM ATA?

[Adam Vande More]

On Thu, Apr 22, 2010 at 10:42 AM, Freddie Cash  wrote:

> If a lowly user's vote counts for anything, I'd vote for the complete
> removal of ataraid support.  We have gstripe, gmirror, graid3, graid5, and
> zfs (and gvinum for the masochistics).  :)  We don't need to support any of
> the crappy pseudo-raid "hardware" out there.  ataraid(4) has served it's
> purpose, tiding us over until GEOM RAID facilities were in place.  Now it's
> time for it to be retired.
>

+1 on ataraid's retirement.

> It doesn't seem to me that sysinstall supports gmirror or gstripe, so
> even if they could be better, currently I think many users still use
> ataraid for simple installations with mirrored disks.

It's hard to say, I'm sure there are some.  It's fairly trivial to create
gmirrors or gstripes after the install is complete.  Also, gstripe's are not
bootable volumes.  Handbook documentation has been guiding users to gmirror
for some time now and gmirror is just much easier to work with IMO.


I think sade(and by further discussion sysinstall) is now getting some
attention and now supports geom devices, zfs, etc at least in one person's
testbed.  I know that's it's been tried before but there are actually
screenshots from it.

http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016418.html


-- 
Adam Vande More
___
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: Switchover to CAM ATA?

[Alex Dupre]

Freddie Cash ha scritto:
>> So what is the public opinion: Is the lack of ataraid(4) fatal or we can
>> live without it?

Lack of ataraid means no more arX devices, right? I'd say it's not fatal
for HEAD, but it is for a -STABLE branch.

> ataraid(4) has served it's
> purpose, tiding us over until GEOM RAID facilities were in place.  Now it's
> time for it to be retired.

It doesn't seem to me that sysinstall supports gmirror or gstripe, so
even if they could be better, currently I think many users still use
ataraid for simple installations with mirrored disks.

-- 
Alex Dupre
___
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 Status Report January-March, 2010

[Daniel Gerzo]

FreeBSD Quarterly Status Report

Introduction

   This report covers FreeBSD related projects between January and March
   2010. Being the first of the four reports planned for 2010 with 46
   entries, it shows a good progress of the FreeBSD Project and proves
   that our committers are keeping up with the latest trends in the OS
   development. During this period, a new minor version of FreeBSD,
   7.3-RELEASE, has been released, while the release process for
   8.1-RELEASE is soon to begin and is planned to be released later this
   summer.

   Thanks to all the reporters for their excellent work! We hope you enjoy
   the reading.

   Please note that the deadline for submissions covering the period
   between April and June 2010 is July 15th, 2010.
 __

Google Summer of Code

 * Google Summer of Code 2010

Projects

 * Chromium web browser
 * Clang replacing GCC in the base system
 * EFI support for FreeBSD/i386
 * mfsBSD
 * Modular Congestion Control
 * NAND Flash framework for embedded FreeBSD
 * Out of Tree Toolchain
 * PC-BSD PC-SysInstall Backend
 * The tbemd branch
 * webcamd

FreeBSD Team Reports

 * FreeBSD Bugbusting Team
 * Release Engineering Team
 * The FreeBSD Foundation

Network Infrastructure

 * (Virtual) Network Stack resource cleanup
 * 802.11n support
 * Atheros AR9285 support
 * Enhancing the FreeBSD TCP Implementation
 * Experimental NFS subsystem (NFSv4)
 * ipfw and dummynet enhancements
 * net80211 rate control framework
 * TCP/UDP connection groups

Kernel

 * CAM-based ATA implementation
 * Dynamic Ticks in FreeBSD
 * geom_sched
 * IPv6 without legacy IP kernel
 * Multichannel playback in HDA sound driver (snd_hda)
 * Rewrite of FreeBSD read/write path using vnode page
 * SUJ: Journaled Softupdates
 * ZFS

Documentation

 * The FreeBSD German Documentation Project
 * The FreeBSD Hungarian Documentation Project

Userland Programs

 * FreeBSD port for libunwind
 * LDAP support in base system

Architectures

 * FreeBSD/arm port for TI DaVinci
 * FreeBSD/ia64
 * FreeBSD/mips on D-Link DIR-320
 * FreeBSD/powerpc
 * FreeBSD/powerpc64 port
 * FreeBSD/sparc64

Ports

 * Portmaster
 * Ports Collection
 * QAT

Miscellaneous

 * BSDCan 2010 -- The BSD Conference
 * meetBSD 2010 -- The BSD Conference
 __

(Virtual) Network Stack resource cleanup

   Contact: Bjoern A. Zeeb 

   In February work was done to address resource leaks in the (virtual)
   network stack, especially on teardown.

   During that time also multiple general run-time problems and leaks were
   identified and fixed including leaked ipfw tables on module unload,
   routing entries leaked, in case of interfaces going away, as well as
   leaked link-layer entries in interaction with flowtable and timers.

   For virtual network stacks resources are are no longer allocated
   multiple times or freed upon teardown for eventhandlers, IP and upper
   level layers, like TCP syncache and host cache, flowtable, and
   especially radix/routing table memory.
   In addition epair(4) was enhanced and debugging was improved.

   This work was sponsored by ISPsystem.

Open tasks:

1. Merge the remaining patches.
2. Work on a better teardown model and get to the point where we can
   free UMA zones without keeping pages for type stability and timers
   around.
 __

802.11n support

   Contact: Rui Paulo 

   802.11n support in the Atheros driver is being worked on. Right now it
   can do AMPDU RX in software and we are working on TX AMPDU. The code
   lives in a private Perforce branch, but some bits of it are already
   committed to HEAD.

   This work is being sponsored by iXsystems, inc.
 __

Atheros AR9285 support

   Contact: Rui Paulo 

   Atheros AR9285 support was added to FreeBSD HEAD and 8-STABLE. There
   are still some issues but in general it works fine.
 __

BSDCan 2010 -- The BSD Conference

   URL: http://www.BSDCan.org/2010/
   URL: http://www.BSDCan.org/2010/schedule/

   Contact: BSDCan Information 

   BSDCan, a BSD conference held in Ottawa, Canada, has quickly
   established itself as the technical conference for people working on
   and with 4.4BSD based operating systems and related projects. The
   organizers have found a fantastic formula that appeals to a wide range
   of people from extreme novices to advanced developers.

   BSDCan 2010 will be held on 13-14 May 2010 at the University of Ottawa,
   and will be preceded by two days of Tutorials on 11-12 May 2010.

   There will be rel

Re: Switchover to CAM ATA?

[Freddie Cash]

2010/4/22 Alexander Motin 

> With time passed, CAM-based ATA infrastructure IMHO looks enough mature
> now to enable it in HEAD. Now we have two new stable drivers ahci(4) and
> siis(4), covering major part of modern SATA HBAs, `options ATA_CAM`
> wrapper for ata(4) to supports legacy hardware, and one more improved
> driver for Marvell HBAs (mvs) is now in development and soon will be
> present for testing. Together with many other people I have tested above
> at least on i386, amd64, arm and spart64 architectures.
>

I haven't updated my 8-STABLE box in a couple of weeks.  Have the issues
with ATAPI DVD-burners been worked out, when using ATA_CAM?  Back in
Jan/Feb, thereabouts, I tested an ATA_CAM kernel and could not get a device
node of any kind to show up for the DVD burner (no acd0, no cd0, nothing in
dmesg).  A non-ATA_CAM kernel shows both acd0 and cd0.

Maybe I'll update my system this weekend and give ATA_CAM another test run.

This switchover would give us significant performance improvement on new
> hardware because of NCQ support in ahci/siis/mvs drivers; improved
> functionality, including SATA Port Multipliers support, better hot-plug
> support; and reduced code duplication between ata(4) and cam(4)
> subsystems and applications.
>
> Two issues left at this moment are:
>  1) POLA breakage due to disk device being renamed from adX to adaY;
>  2) lack of araraid(4) alternative in new infrastructure. It should be
> reimplemented in GEOM in some way, but it still wasn't.
>
> So what is the public opinion: Is the lack of ataraid(4) fatal or we can
> live without it?
>
> Can we do switchover now, or some more reasons preventing this?
>
> If ataraid(4) should be reimplemented in GEOM, then how exactly? One
> more separate RAID infrastructure in GEOM (third?) looks excessive.
> Reuse gmirror, gstripe,... code would be nice, but will make them more
> complicated and could be not easy for RAID0+1 (due to common metadata)
> and RAID5 (due to lack of module in a base system).


If a lowly user's vote counts for anything, I'd vote for the complete
removal of ataraid support.  We have gstripe, gmirror, graid3, graid5, and
zfs (and gvinum for the masochistics).  :)  We don't need to support any of
the crappy pseudo-raid "hardware" out there.  ataraid(4) has served it's
purpose, tiding us over until GEOM RAID facilities were in place.  Now it's
time for it to be retired.

-- 
Freddie Cash
fjwc...@gmail.com
___
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"

Switchover to CAM ATA?

[Alexander Motin]

Hi.

With time passed, CAM-based ATA infrastructure IMHO looks enough mature
now to enable it in HEAD. Now we have two new stable drivers ahci(4) and
siis(4), covering major part of modern SATA HBAs, `options ATA_CAM`
wrapper for ata(4) to supports legacy hardware, and one more improved
driver for Marvell HBAs (mvs) is now in development and soon will be
present for testing. Together with many other people I have tested above
at least on i386, amd64, arm and spart64 architectures.

This switchover would give us significant performance improvement on new
hardware because of NCQ support in ahci/siis/mvs drivers; improved
functionality, including SATA Port Multipliers support, better hot-plug
support; and reduced code duplication between ata(4) and cam(4)
subsystems and applications.

Two issues left at this moment are:
 1) POLA breakage due to disk device being renamed from adX to adaY;
 2) lack of araraid(4) alternative in new infrastructure. It should be
reimplemented in GEOM in some way, but it still wasn't.

So what is the public opinion: Is the lack of ataraid(4) fatal or we can
live without it?

Can we do switchover now, or some more reasons preventing this?

If ataraid(4) should be reimplemented in GEOM, then how exactly? One
more separate RAID infrastructure in GEOM (third?) looks excessive.
Reuse gmirror, gstripe,... code would be nice, but will make them more
complicated and could be not easy for RAID0+1 (due to common metadata)
and RAID5 (due to lack of module in a base system).

-- 
Alexander Motin
___
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: [CFT]: ClangBSD is selfhosting, we need testers now

[Ulrich Spörlein]

On Wed, 21.04.2010 at 23:30:15 +0200, Alexander Best wrote:
> Roman Divacky schrieb am 2010-04-21:
> > On Wed, Apr 21, 2010 at 09:44:45PM +0200, Alexander Best wrote:
> > > Roman Divacky schrieb am 2010-04-21:
> 
> > > [snip]
> 
> > > > 1) cd modules/sound/sound && make CC=gcc
> 
> > > after this step these are the sizes of sound.ko* in
> > > modules/sound/sound:
> 
> > > -rw-r--r--  1 root  wheel   449120 Apr 21 21:36 sound.ko
> > > -rw-r--r--  1 root  wheel  2284757 Apr 21 21:36 sound.ko.debug
> > > -rw-r--r--  1 root  wheel  2055512 Apr 21 21:36 sound.ko.symbols
> 
> > > > 2) make -V SRCS | tr " " "\n" | grep -v \.h | sort | grep
> > > >"^[a-m].*"
> > > >| xargs touch
> 
> > this line is wrong.. it creates empty files which are used instead
> > of touching the existing ones...  it needs to be adjusted so it
> > touches the files (thus forcing them to be rebuilt with the second
> > make invocation)
> 
> i'm now 100% sure that buffer.c is causing the problem. what i did to verify
> this was:
> 
> cd sys/modules/sound/sound && make CC=clang && touch
> ../../../dev/sound/pcm/buffer.c && make CC=gcc && make install
> 
> this gives me working sound!

Great stuff to have narrowed it down so much. Next logical step would be
to do the bisect on function-level scope.

Copy one half of buffer.c to buffer-clang.c, the other half to buffer-gcc.c,
adjust the Makefile to use buffer-{gcc,clang}.c instead of buffer.c and
compile them accordingly. Redo your tests till we know the single function(s)
where clang produces bad code.

Hang in there, the hard part is almost done!
Uli
___
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: newsyslog patch implementing file includes

[John Baldwin]

On Wednesday 21 April 2010 11:55:44 pm Gordon Tetlow wrote:
> I wanted the ability for a port to have a rotating log policy so I wrote a
> patch for newsyslog to implement includes of other newsyslog.conf style
> files.
> 
> Please find the patch at:
> 
http://people.freebsd.org/~gordon/patches/newsyslog.diff
> 
> Format for the include line in /etc/newsyslog.conf is:
>  /etc/defaults/newsyslog.conf
> 
> Here's a quick overview of the changes:
> Convert the conf_entry struct from using a home rolled linked list to the
> queue(3) macros.
> Add a STAILQ to process include files.
> Add support for  tag to specify include files.
> Globbing is supported in  statements.
> Properly detect circular include loop dependencies.
> 
> Please take a look and send me any comments you might have.

This is a great feature!  One suggestion, I think this text in the new manpage 
isn't quite right:

  Name of the system log file to be archived, the literal string "default",
  or "include".

I think it's ambiguous about "include" also being a literal string.  Two 
possible suggestions:

  Name of the system log file to be archived, or one of the literal strings
  "default" or "include".

  Name of the system log file to be archived, the literal string "default",
  or the literal string "include".

-- 
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: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

[John Baldwin]

On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote:
> Maxim Sobolev wrote:
> > There is already a code to detect non-existing AT keyboard and avoid 
> > attaching atkbd to it. The code is i386-only at the moment, I am trying 
> > to figure out how to modify it so that it works on amd64 as well.
> 
> Looks like this huge delay is caused by the inb() being astonishingly 
> slow, which is not factored by the timeout routines. Reading keyboard 
> status port once takes about 0.003s! I am not sure if it's common 
> behaviour of the platform, or something specific to this particular 
> model. Do you know by any chance?

Well, many BIOSes trigger an SMI# when doing inb/outb to the keyboard ports so 
they can emulate a PS/2 keyboard when a USB keyboard is inserted.  Do you have 
any BIOS options related to the USB legacy compat?  I know of the Nehalem 
systems I've seen they have a separate option for controlling port 60/64 
emulation which we leave disabled by default.

-- 
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: newsyslog patch implementing file includes

[Gordon Tetlow]

On Thu, Apr 22, 2010 at 12:17 AM, Alex Keda  wrote:

> It's need feature. I test patch - it work for me (CURRENT, amd64)
> Can I use some as:
>  /path/to/dir/*.conf
> ?
> and can I create recursive include?
>

Yes, wildcards and recursive includes are supported.

Gordon
___
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: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

[Maxim Sobolev]

Maxim Sobolev wrote:
There is already a code to detect non-existing AT keyboard and avoid 
attaching atkbd to it. The code is i386-only at the moment, I am trying 
to figure out how to modify it so that it works on amd64 as well.


Looks like this huge delay is caused by the inb() being astonishingly 
slow, which is not factored by the timeout routines. Reading keyboard 
status port once takes about 0.003s! I am not sure if it's common 
behaviour of the platform, or something specific to this particular 
model. Do you know by any chance?


-Maxim
___
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: newsyslog patch implementing file includes

[krad]

On 22 April 2010 08:33, Alex Keda  wrote:

> 22.04.2010 11:29, Gordon Tetlow ?:
>
>> On Thu, Apr 22, 2010 at 12:17 AM, Alex Keda > ad...@lissyara.su>> wrote:
>>
>>It's need feature. I test patch - it work for me (CURRENT, amd64)
>>Can I use some as:
>> /path/to/dir/*.conf
>>?
>>and can I create recursive include?
>>
>>
>> Yes, wildcards and recursive includes are supported.
>>
> great job!
> Thanks!
>
>
> ___
> 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"
>


i would be real nice is newsyslog also supported a date based file renaming
shceme rather than the cyclic 0,1,2,3, much like the datext option in
logrotate. eg

messages
messages.20100422
messages.20100421
messages.20100420
...

The cyclic renaming is a pain for incremental backups as all the log files
are backed up every time as their contents changes compared to their
filename
___
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: Does "makeoptions WITH_CTF=yes" actually work?

[Alexander Leidinger]

Quoting Navdeep Parhar  (from Thu, 22 Apr 2010  
01:33:22 -0700):



On Thu, Apr 22, 2010 at 09:44:47AM +0200, Alexander Leidinger wrote:

Quoting Navdeep Parhar  (from Wed, 21 Apr 2010
18:23:33 -0700):

>Your patch works for me, thanks.  There is just one more problem  
with the CTF


I found a case where it does not work (not kernel related), I have
another one which works better.

>generation that needs to be fixed:
>
>http://lists.freebsd.org/pipermail/freebsd-hackers/2009-April/028244.html
>
>While you're here can you take a look at the patch in that email too?

Looks good in concept, but the CTFMERGE line needs the same
treatment like all the other ones in the .mk files. I want to commit
a suitable change today.


Does "same treatment" mean it should run silently too?  My personal


Yes.


opinion is that all ctfconvert and ctfmerge commands should show up in
the output of make iff they run.  I believe that used to be the case
before r206082.


Correct, and I agree.

The problem is the inverse-logic construct for the check if it shall  
be run or not which is consistent with all places where this is done.  
There is no easy way to only display a part of the command which is  
executed. It was decided by ... (jhb and rwatson?) to not display at  
all while we still have the default to without ctf (without the @ we  
will even have some display of something with ctfconvert or ctfmerge  
in the name, when no ctf info is put into the files). They want to  
have the default to with ctf when it is ready/stable enough. I assume  
that at this point the commands get shown again, as the handling of  
the with/without CTF stuff can be simplified in this case. It is not  
as easy as all the other with/without stuff we have, due to the fact  
that parts of the ctf stuff is in sys.mk, which is read before every  
other file.


Currently I want to finish the edge cases we noticed in a *consistent*  
way, to have something which is giving us stable behavior. After that  
I will go out of the loop and anyone is free to try/optimize what he  
wants (as long as I can get a kernel compiled with CTF info without  
much hassle, I do not care much what is done and how).


HTH,
Alexander.

--
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org  : PGP ID = 72077137
A hermit is a deserter from the army of humanity.

___
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: Does "makeoptions WITH_CTF=yes" actually work?

[Navdeep Parhar]

On Thu, Apr 22, 2010 at 09:44:47AM +0200, Alexander Leidinger wrote:
> Quoting Navdeep Parhar  (from Wed, 21 Apr 2010
> 18:23:33 -0700):
> 
> >Your patch works for me, thanks.  There is just one more problem with the CTF
> 
> I found a case where it does not work (not kernel related), I have
> another one which works better.
> 
> >generation that needs to be fixed:
> >
> >http://lists.freebsd.org/pipermail/freebsd-hackers/2009-April/028244.html
> >
> >While you're here can you take a look at the patch in that email too?
> 
> Looks good in concept, but the CTFMERGE line needs the same
> treatment like all the other ones in the .mk files. I want to commit
> a suitable change today.

Does "same treatment" mean it should run silently too?  My personal
opinion is that all ctfconvert and ctfmerge commands should show up in
the output of make iff they run.  I believe that used to be the case
before r206082.

Regards,
Navdeep
___
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: Does "makeoptions WITH_CTF=yes" actually work?

[Alexander Leidinger]

Quoting Navdeep Parhar  (from Wed, 21 Apr 2010  
18:23:33 -0700):



Your patch works for me, thanks.  There is just one more problem with the CTF


I found a case where it does not work (not kernel related), I have  
another one which works better.



generation that needs to be fixed:

http://lists.freebsd.org/pipermail/freebsd-hackers/2009-April/028244.html

While you're here can you take a look at the patch in that email too?


Looks good in concept, but the CTFMERGE line needs the same treatment  
like all the other ones in the .mk files. I want to commit a suitable  
change today.


Bye,
Alexander.

--
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org  : PGP ID = 72077137
"I have to get back to New York tomorrow, so think about your price."
-- Michael Corleone, "Chapter 27", page 386

___
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: newsyslog patch implementing file includes

[Alex Keda]

22.04.2010 11:29, Gordon Tetlow ?:
On Thu, Apr 22, 2010 at 12:17 AM, Alex Keda > wrote:


It's need feature. I test patch - it work for me (CURRENT, amd64)
Can I use some as:
 /path/to/dir/*.conf
?
and can I create recursive include?


Yes, wildcards and recursive includes are supported.

great job!
Thanks!

___
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: newsyslog patch implementing file includes

[Alex Keda]

22.04.2010 07:55, Gordon Tetlow пишет:

I wanted the ability for a port to have a rotating log policy so I wrote a
patch for newsyslog to implement includes of other newsyslog.conf style
files.

Please find the patch at:
http://people.freebsd.org/~gordon/patches/newsyslog.diff

Format for the include line in /etc/newsyslog.conf is:
  /etc/defaults/newsyslog.conf

Here's a quick overview of the changes:
Convert the conf_entry struct from using a home rolled linked list to the
queue(3) macros.
Add a STAILQ to process include files.
Add support for  tag to specify include files.
Globbing is supported in  statements.
Properly detect circular include loop dependencies.

Please take a look and send me any comments you might have.

It's need feature. I test patch - it work for me (CURRENT, amd64)
Can I use some as:
 /path/to/dir/*.conf
?
and can I create recursive include?
___
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"