Re: newsyslog patch implementing file includes
On Sat, Apr 24, 2010 at 2:57 AM, Garance A Drosehn wrote: > At 10:15 AM +0100 4/22/10, krad wrote: >> >> 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! > > I also think this is a great feature to add. > > Just to be clear: This allows a config file to include some other > file, and that other file can also include more files with additional > newsyslog entries. In that sense it allows recursive includes. > > Note that it will detect when such recursion causes one file to end > up indirectly including itself, and will reject *that* situation. > So you shouldn't be able to get into an infinite loop of included > files. This sounds cool; I've ever ran into a situation where I needed this -- yet. Although I'm sure when it's in the tree and available, I'll not be able to live without it :) >> 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 > > I hope to do this after Gordon commits the new feature that he's > implemented. I know I've said that before, but I do have some > vacation time coming up soon and expect to do it then. > > -- > Garance Alistair Drosehn = dros...@rpi.edu > Senior Systems Programmer or g...@freebsd.org > Rensselaer Polytechnic Institute; Troy, NY; USA This would indeed be a very welcome feature. I've been trying to devise a method (and the logic) to do something similar recently... I wonder, what might the time-frame be for adding the above feature? A "guess-timate" would be OK :) -Brandon ___ 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
At 10:15 AM +0100 4/22/10, krad wrote: 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 > 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! I also think this is a great feature to add. Just to be clear: This allows a config file to include some other file, and that other file can also include more files with additional newsyslog entries. In that sense it allows recursive includes. Note that it will detect when such recursion causes one file to end up indirectly including itself, and will reject *that* situation. So you shouldn't be able to get into an infinite loop of included files. 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 I hope to do this after Gordon commits the new feature that he's implemented. I know I've said that before, but I do have some vacation time coming up soon and expect to do it then. -- Garance Alistair Drosehn = dros...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA ___ 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: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
I have a Dell Zino HD (Mac mini clone, with eSATA ports) that uses the BCM4353 chip (called a Dell 1520 card) no...@pci0:2:0:0:class=0x028000 card=0x000e1028 chip=0x435314e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' class = network Should I expect this to work with to work here or try the NDIS driver? ___ 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: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 En/na Weongyo Jeong ha escrit: > On Wed, Mar 03, 2010 at 11:10:14AM +0200, Alexandr Rybalko wrote: >> On Wed, 3 Mar 2010 00:28:33 -0800 >> Weongyo Jeong wrote: > I've been testing the driver for a few time with AMD64/CURRENT. A few time ago I started to see messages like : bwn0: unsupported rate 0 I've checked the code and I found it seems to fail when trying to check the TX rate at if_bw.c:9561 (in bwn_ieeerate2hwrate routine the rate parameter is 0). I checked where bwn_ieeerate2hwrate is called, to see how 'rate' is calculated. This is where I got lost :( My AP is FreeBSD 8.0 box with an atheros card. My hostapd works with both WPA2-PSK and WPA2-EAP (although I thinks this is not the problem) but with default values for rates and friends. I then forced my hostapd to use only a subset of transmit rates (with supported_rates and basic_rates) with no luck. My laptop is a DELL D630 with a BCM4310 UART adapter. Any need info will be provided and any help will be appreciated. Best regards, Gus - -- PGP KEY : http://www-entel.upc.edu/gus/gus.asc -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJL0iAeAAoJEH+VVM1WSYnPH+oQAJXnve4bzhB1pzTr1HhMkXCZ hqveStvnbIxvLV0n8RjH1vK5XFK8Cr1zofGb/btfcnIaW2tBuItVLxpbKP3pEnd0 /FKZZ68ngcNmX8jDyQ1ea6JbQNnJbkM3VIOymwoOhz2rDFCG8JiEGNVMeBDkVdgU 1gitBsrNIWo7WLikmskSbgm9Xb5JsHNGxe6C6L7VGKOdd7ywvokihgctXaEd9o52 jFtnmJYnvFT+q6e+SCRpqYpAiBQSwfbQe/qx+oPsaQGwczskwO5YqzKEonY2U/XR GOKe1fPQzzdqKtpa/cDfwPt7H0GbaDdJaBhj1voSfn3/tguKIgYCVU49/jq8V0/a NkF8VDw2j9eDOgTZP+Uub9PJvp5Tn5kG6SsAOjPxV01U5ouRBzVenDTems8JizLH GD1ldRjnRg9o4XqRgee8wUDqiEiTu2n7vwyttp2PtOUrrB4Ed11pNcYGkEyiPuLG K3UhLPlN1lh5lSlNofeD6zq4fDlaXmfxjCBvQRADk2HSaLnCp4hqoqydKvGvG5mg nexYi+XQY17u5PsPKNPKHM/aS5dmsBgrOgMCMXNuC/65YGxS4lca4m3QSYYES+qU dfhrhQ2pD24/ysvYwekd3nVbMXBjtU97a07r2aJPiidQYZ0erTtG7dEHrGFwGXmm XEwHkkANz3NMl/skGJc5 =7IfN -END PGP SIGNATURE- ___ 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?
On Fri, Apr 23, 2010 at 09:40:59AM +0300, Andriy Gapon wrote: > 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. That seems to be it, the perms on pass1 needed fixing. Thanks for the tip! -- 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: IPv6 configuration in rc.d
Hiroki,
Throughout your post you are *theorizing* about what you *think* will
happen. You obviously missed the parts of my post(s) where I said I
actually tested it.
BEFORE you make any changes to the existing code you need to do some
actual testing, publish your methods and results, make a persuasive
argument for your proposed changes, and let other people review your
work and have a chance to respond.
I feel that I have tried very hard to be patient here, and I continue to
have deep appreciation for the hard work that you've put into this.
However I think your current stance is unreasonable, and what you've
said in this post essentially amounts to "If I don't get my way I'm
going to pick up my toys and go home." That's not an appropriate method
of interaction for a committer, and I don't appreciate being placed in
the situation of having to repeatedly ask you to act in a reasonable
manner.
More comments below.
On 04/23/10 08:26, Hiroki Sato wrote:
> Doug Barton wrote
> in <4bcb6a14.5040...@freebsd.org>:
>
> do> > # ifconfig gif0 create
> do> > # ifconfig gif0 up
> do>
> do> Your statement is literally true, in this case the network.subr stuff
> do> "has no control" because it isn't run. That was the same for the old
> do> code as it is for the new code.
>
> No, in this case devd(8) invokes rc.d/netif as it is created. The
> old code does "ifconfig inet6 -ifdisabled" before it becomes "up"
> when ipv6_prefer=YES, and the new code always does "ifconfig inet6
> ifdisabled" when no ifconfig_gif0_ipv6 line, respectively.
As I said in my previous post:
1. Based on my testing the code in ifconfig_up() in network.subr that
does what you're referring to is not run when you ifconfig a *gif*
interface on the command line. I realize that it IS run for other
interfaces.
2. The case of people randomly creating tunnels on the command line is
an edge case, almost all network configuration happens in rc.conf, and
EVEN IF it is required to add a line or two more than we have to do now
in order to make tunnel configuration work, that is not too high a price
to pay for a clean, consistent user interface.
> do> Note that IPv6 link-local addresses (those that start with fe80::) will
> do> be automatically configured whenever possible. You may need to remove
> do> IPv6 link-local addresses manually using ifconfig(8) ...
>
> No, the ifdisabled flag set via devd(8) prevents this.
The gif man page section that I quoted seems to indicate that enough
people wanted to REMOVE the link-local addresses that it was worth
mentioning explicitly how to do it. It's not at all clear to me that
what you are proposing (auto-magic configuration of link-local for
tunnels) is even what the majority of users want.
> do> > IPv4 people hates that gif0 has an IPv6 link-local (and IPv6
> do> > communication itself),
> do>
> do> People who don't want v6 at all compile it out of the kernel, and the
> do> whole problem goes away. The project made a decision a long time ago to
> do> ship with v6 in GENERIC, so this is not a new issue.
>
> No, the auto link-local addr assignment was turned to off by default
> some years ago for this reason. This was a secteam's decision after
> IPv6 was included in GENERIC. This is an issue for both IPv4 and
> IPv6 people.
LOL ... If what you're saying is accurate then you're actually trying
to subvert the defaults, not "restore" them. If the secteam decided that
link-local addresses should not be created by default then even if your
description of what the current code does is accurate, it is doing
exactly what it should be doing.
> do> > and IPv6 people hates that it needs an
> do> > additional step to enable it (ifconfig inet6 -ifdisabled in this
> do> > case). gif (and other cloned interfaces) can be created by a program
> do> > (a ppp script, for example), so we cannot prepare $ifconfig line in
> do> > rc.conf in advance.
> do>
> do> Why not? There is no reason you can't have ifconfig_* lines for
> do> interfaces that are not always configured, I do it all the time.
>
> Because the interface identifier cannot always be known in advance.
>
> For example, IPv6 tunnel server/client which accept an incoming
> connection and establish a gif tunnel between the two create a lot of
> gif interfaces on demand, and the created gif interfaces must be
> ready for IPv6 without "ifconfig -ifdisabled" if the sysadmin wants
> IPv6. The net/dtcp{,client} in the ports collection is one of the
> typical applications. This situation is also common in a
> linkup/linkdown scripts for PPP(IPV6CP). Having all possible
> interface names in rc.conf is not practical even if the number of
> interfaces is small. IPv6 people (including me) surely want a knob
> for "-ifdisabled on interfaces with no $ifconfig line in rc.conf" if
> an interface has the ifdisabled flag. Without it, such kind of
> programs do not work.
Please provide actual examples of what you're describing that I can s
Re: Switchover to CAM ATA?
Hello, Nenhum_de_Nos.
You wrote 23 апреля 2010 г., 09:08:05:
>> > 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 ?
Unfortunalety, it means graid5 in ports only for now. But in
future... who knows?
--
// 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: Switchover to CAM ATA?
On 2010-04-23, Scott Long wrote: > My advice is to retrain your fingers to use cdrecord. Burncd is > highly specific to the old ata driver, and "adding SCSI support" to it > would likely involve a complete rewrite. Well, I did that by porting parts of acd(4) to user space. -- Jaakko ___ 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?
On Fri, Apr 23, 2010 at 1:41 AM, Paul Wootton wrote: > Alexander Motin wrote: > >> >> Can we do switchover now, or some more reasons preventing this? >> >> The only thing I miss about the old ATA layer was that I knew that a drive > on a particular controller would always be assigned the same adX number, > whether is was present at boot time, or added days later. This could get a > little messy having ad2, ad4, ad12, ad20 and ad22, but at least if I added a > new drive, it would always attach to say ad8. > > Can this be done on the new CAM ATA? I have not tried it with ATA_CAM, but in theory, you should be able to wire things down the same as with SCSI devices. Just takes a bit of mucking around with camcontrol output, and sticking the right info into /boot/loader.conf. See the man page for camcontrol for all the details. -- 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"
Re: IPv6 configuration in rc.d
Doug Barton wrote
in <4bcb6a14.5040...@freebsd.org>:
do> > # ifconfig gif0 create
do> > # ifconfig gif0 up
do>
do> Your statement is literally true, in this case the network.subr stuff
do> "has no control" because it isn't run. That was the same for the old
do> code as it is for the new code.
No, in this case devd(8) invokes rc.d/netif as it is created. The
old code does "ifconfig inet6 -ifdisabled" before it becomes "up"
when ipv6_prefer=YES, and the new code always does "ifconfig inet6
ifdisabled" when no ifconfig_gif0_ipv6 line, respectively.
do> Note that IPv6 link-local addresses (those that start with fe80::) will
do> be automatically configured whenever possible. You may need to remove
do> IPv6 link-local addresses manually using ifconfig(8) ...
No, the ifdisabled flag set via devd(8) prevents this.
do> > IPv4 people hates that gif0 has an IPv6 link-local (and IPv6
do> > communication itself),
do>
do> People who don't want v6 at all compile it out of the kernel, and the
do> whole problem goes away. The project made a decision a long time ago to
do> ship with v6 in GENERIC, so this is not a new issue.
No, the auto link-local addr assignment was turned to off by default
some years ago for this reason. This was a secteam's decision after
IPv6 was included in GENERIC. This is an issue for both IPv4 and
IPv6 people.
do> > and IPv6 people hates that it needs an
do> > additional step to enable it (ifconfig inet6 -ifdisabled in this
do> > case). gif (and other cloned interfaces) can be created by a program
do> > (a ppp script, for example), so we cannot prepare $ifconfig line in
do> > rc.conf in advance.
do>
do> Why not? There is no reason you can't have ifconfig_* lines for
do> interfaces that are not always configured, I do it all the time.
Because the interface identifier cannot always be known in advance.
For example, IPv6 tunnel server/client which accept an incoming
connection and establish a gif tunnel between the two create a lot of
gif interfaces on demand, and the created gif interfaces must be
ready for IPv6 without "ifconfig -ifdisabled" if the sysadmin wants
IPv6. The net/dtcp{,client} in the ports collection is one of the
typical applications. This situation is also common in a
linkup/linkdown scripts for PPP(IPV6CP). Having all possible
interface names in rc.conf is not practical even if the number of
interfaces is small. IPv6 people (including me) surely want a knob
for "-ifdisabled on interfaces with no $ifconfig line in rc.conf" if
an interface has the ifdisabled flag. Without it, such kind of
programs do not work.
Of course we can fix the programs to always use -ifdisabled, but the
ifdisabled flag should not become popular for users. I reluctantly
designed the ifdisabled flag only for IPv4 people who hate a
link-local addr, in order to make IPv6 enabled by default as much as
possible with minimal impact to them as well as IPv6 people. This is
*the reason* why I improved the ifdisabled flag and used it in the
rc.d scripts. This has no compatibility with other KAME-derived
implementation, and for IPv6 people it is nothing but an annoying
obstacle.
The ifdisabled flag never disables the IPv6 functionality, and it can
make various wired situations for IPv6 people because the
functionality is enabled but the communication including the critical
ones is disabled. It can be used only as a seatbelt for IPv4 people;
not as a generic way to disable IPv6 on an interface. My design was
discussed with ex-KAME members last year and we all agreed that the
ifdisabled flag should not be abused in a way other than that. You
can see the difference between "disabling the functionality" and
"disabling the communication" if you read sys/netinet6*.
Anyway, if we will go ahead with "to use IPv6 please do ifconfig
inet6 -ifdisabled first" or "please always add the interface name to
rc.conf" as the current implementation does, I will revert my changes
which added support of the ifdisabled flag into ifconfig before
BSDCan. This flag is just needed to solve the issues I explained in
this and previous emails. If my concerns are just an illusion,
removing the flag makes the world much simpler.
do> Are you theorizing here, or do you have actual examples? If you can find
do> actual examples of "here is something that used to work, but now it does
do> not" then we can work on a solution. I am not necessarily opposed to the
do> idea of automatically creating link-local addresses for cloned
do> interfaces, but it's impossible for me to code against something I don't
do> have in front of me. :)
See tunnel server/client programs like what I described above and/or
try to build an L2TP over UDP concentrator which uses IPV6CP +
DHCPv6-PD.
-- Hiroki
pgpwpyd3Z4xFT.pgp
Description: PGP signature
Re: Switchover to CAM ATA?
John Baldwin wrote: > On Thursday 22 April 2010 11:31:37 am Alexander Motin wrote: >> 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). > > Scott's view (which sounds good to me) is that GEOM should include a library > of routines for working with common transforms such as RAID1, striping, etc. > Each ATA RAID vendor format would then consist of a small GEOM module that > used the library routines to manage all the I/O and the bulk of the module > would be managing a specific metadata format. Yes, I remember he proposed it somewhere. Idea is fine. Somebody with sharp axe and lack of fear should just chop half of GEOM modules into small pieces and collect them back. ;) -- 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: Switchover to CAM ATA?
On Apr 23, 2010, at 7:50 AM, John Baldwin wrote: > On Thursday 22 April 2010 11:31:37 am Alexander Motin wrote: >> 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). > > Scott's view (which sounds good to me) is that GEOM should include a library > of routines for working with common transforms such as RAID1, striping, etc. > Each ATA RAID vendor format would then consist of a small GEOM module that > used the library routines to manage all the I/O and the bulk of the module > would be managing a specific metadata format. > THIS It's hard for me to talk about RAID and FreeBSD without getting into a long sermon, so I'll try to keep this short. RAID is about data integrity, not about mirror/stripe/parity algorithms. Those algorithms are just a small part of RAID, and are merely tools for achieving the goals of RAID. But RAID != algorithms. It's like how we use linked lists extensively within the kernel, but the kernel != linked lists. A well-designed software raid stack is going to be an engine that manages topology, executes and rolls back I/O transactions, and handles error recovery. On-disk metadata is again just an algorithm that is part of this whole picture, and should be modularized as such along with the transforms. And to be even more brief, the existing GEOM RAID modules are designed in completely the wrong direction from this. Caveat Emptor. Scott ___ 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?
On Apr 23, 2010, at 8:00 AM, Jaakko Heinonen wrote: > On 2010-04-23, Alexander Best wrote: >> has anybody thought about adding scsi support to burncd(8)? i've been using >> ATA CAM for quite a while now and really love it. however i miss burncd(8). > > I have thought about it. The mail I posted in December didn't generate > any interest. > > http://docs.freebsd.org/cgi/mid.cgi?20091214182645.GA2764 > My advice is to retrain your fingers to use cdrecord. Burncd is highly specific to the old ata driver, and "adding SCSI support" to it would likely involve a complete rewrite. Scott ___ 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?
On Fri, Apr 23, 2010 at 09:50:33AM -0400, John Baldwin wrote: > On Thursday 22 April 2010 11:31:37 am Alexander Motin wrote: > > 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). > > Scott's view (which sounds good to me) is that GEOM should include a library > of routines for working with common transforms such as RAID1, striping, etc. > Each ATA RAID vendor format would then consist of a small GEOM module that > used the library routines to manage all the I/O and the bulk of the module > would be managing a specific metadata format. I remember that SCSI standard has support for xor read-modify-write operations in addition to normal read/write to reduce R5 latency and bandwith. I'm not sure if any devices actually support it, but I think this may be worthwhile for networked devices. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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?
On 2010-04-23, Alexander Best wrote: > has anybody thought about adding scsi support to burncd(8)? i've been using > ATA CAM for quite a while now and really love it. however i miss burncd(8). I have thought about it. The mail I posted in December didn't generate any interest. http://docs.freebsd.org/cgi/mid.cgi?20091214182645.GA2764 -- Jaakko ___ 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?
On Thursday 22 April 2010 11:31:37 am Alexander Motin wrote: > 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). Scott's view (which sounds good to me) is that GEOM should include a library of routines for working with common transforms such as RAID1, striping, etc. Each ATA RAID vendor format would then consist of a small GEOM module that used the library routines to manage all the I/O and the bulk of the module would be managing a specific metadata format. -- 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: MCA messages in /var/log/message?
On Thursday 22 April 2010 6:28:34 pm Steve Kargl wrote: > 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). If you have access to p4, you can download a patched version of mcelog from //depot/projects/mcelog/... (have to use 'make FREEBSD=yes') which will parse these for you. Hmm, I ran it and here is what it said: HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 4 northbridge ADDR 70c42280 Northbridge RAM Chipkill ECC error Chipkill ECC syndrome = d6b4 bit46 = corrected ecc error bus error 'local node response, request didn't time out generic read mem transaction memory access, level generic' STATUS 945a4000d6080a13 MCGSTATUS 0 MCGCAP 105 APICID 0 SOCKETID 0 CPUID Vendor AMD Family 15 Model 5 HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 1 4 northbridge ADDR 1b97ca578 Northbridge RAM Chipkill ECC error Chipkill ECC syndrome = 2a42 bit32 = err cpu0 bit46 = corrected ecc error bus error 'local node origin, request didn't time out generic read mem transaction memory access, level generic' STATUS 942140012a080813 MCGSTATUS 0 MCGCAP 105 APICID 1 SOCKETID 0 CPUID Vendor AMD Family 15 Model 5 Note that they are corrected errors, so the RAM may not actually be bad, it just may be transient failures. -- 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: Switchover to CAM ATA?
On 04/23/10 14:32, Andriy Gapon wrote: on 23/04/2010 12:28 Alexander Best said the following: has anybody thought about adding scsi support to burncd(8)? i've been using ATA CAM for quite a while now and really love it. however i miss burncd(8). i found it to be much easier to use and less buggy than cdrecord(1). burncd for CAM (SCSI, ATAPI) will be something very close to cdrecord or growisofs. How different are the interfaces? I mean - since they talk to the same device, are the differences just API / superficial or is there something fundamentally different that cannot be implemented within burncd? (I agree that burncd is very nice to have and more logical to use than cdrecord.) ___ 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?
on 23/04/2010 12:28 Alexander Best said the following: > has anybody thought about adding scsi support to burncd(8)? i've been using > ATA CAM for quite a while now and really love it. however i miss burncd(8). i > found it to be much easier to use and less buggy than cdrecord(1). burncd for CAM (SCSI, ATAPI) will be something very close to cdrecord or growisofs. -- 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
Hello, Can you try this? (all 3 files has been updated) http://projects.nasreddine.com/projects/run/repository/revisions/mips_fix/show/dev/usb/wlan This is for rev 207077 or newer. If you are using older rev, please let me know with rev #, I'll change the code accordingly. If it isn't too much trouble, can you run the driver with following debug option on? # wlandebug -i wlan0 0x6930 (after wlan create) To make this work, kernel need to be compiled with IEEE80211_DEBUG option which is enabled in generic AR71XX conf file by default. And, maybe with INVARIANTS option? the bug has been fixed in rev 206400 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/mips/atheros/if_arge.c Sorry for asking too much. The driver is causing the trouble, but something goes wrong outside the driver. Thanks AK > >> Is your kernel compiled with INVARIANTS >> option? >> > Tried, but if_arge panics at boot with INVARIANTS > option. > arge0: at > mem 0x1900-0x19000fff irq 2 on nexus0 panic: mtx_lock() of spin mutex > arge mii lock > @ /usr/mysrc/sys/mips/atheros/if_arge.c:554 > thanks, > Ganbold ___ 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?
Paul Wootton wrote: > Alexander Motin wrote: >> Can we do switchover now, or some more reasons preventing this? > > The only thing I miss about the old ATA layer was that I knew that a > drive on a particular controller would always be assigned the same adX > number, whether is was present at boot time, or added days later. This > could get a little messy having ad2, ad4, ad12, ad20 and ad22, but at > least if I added a new drive, it would always attach to say ad8. > > Can this be done on the new CAM ATA? Binding to controller ports and device IDs can be managed for any CAM device via device.hints as described in cam(4). This scheme is a slightly more complicated (you have to explicitly define wanted mapping), but more flexible. Previous one just inapplicable now. Modern controllers (especially with Port Multipliers) could support different (often big) number of devices per channel, making device list with static numbering too sparse. -- 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: Switchover to CAM ATA?
has anybody thought about adding scsi support to burncd(8)? i've been using ATA CAM for quite a while now and really love it. however i miss burncd(8). i found it to be much easier to use and less buggy than cdrecord(1). since eventually the whole ata(4) subsystem will be dumped in favour of cam(4) i guess the fate of ata(4) dependant binaries in the base should also be discussed. maybe somebody could put together a list of ata(4) dependant binaries currently in base in addition to burncd(8) and atacontrol(8)? -- 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?
Alexander Motin wrote: Can we do switchover now, or some more reasons preventing this? The only thing I miss about the old ATA layer was that I knew that a drive on a particular controller would always be assigned the same adX number, whether is was present at boot time, or added days later. This could get a little messy having ad2, ad4, ad12, ad20 and ad22, but at least if I added a new drive, it would always attach to say ad8. Can this be done on the new CAM ATA? Paul ___ 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: HEADS UP: SUJ Going in to head today
On Wed, 21 Apr 2010, Garrett Cooper wrote: On Wed, Apr 21, 2010 at 12:39 AM, Gary Jennejohn wrote: On Tue, 20 Apr 2010 12:15:48 -1000 (HST) Jeff Roberson wrote: Hi Folks, You may have seen my other Soft-updates journaling (SUJ) announcements. If not, it is a journaling system that works cooperatively with soft-updates to eliminate the full background filesystem check after an unclean shutdown. SUJ may be enabled with tunefs -j enable and disabled with tunefs -j disable on an unmounted filesystem. It is backwards compatible with soft-updates with no journal. I'm going to do another round of tests and buildworld this afternoon to verify the diff and then I'm committing to head. This is a very large feature and fundamentally changes softupdates. Although it has been extensively tested by many there may be unforseen problems. If you run into an issue that you think may be suj please email me directly as well as posting on current as I sometimes miss list email and this will ensure the quickest response. And the crowd goes wild. SUJ is _great_ and I'm glad to see it finally making it into the tree. Indeed. I'm looking forward to testing the junk out of this -- this is definitely a good move forward with UFS2 :]... Cheers, -Garrett PS How does this interact with geom with journaling BTW? Has this been tested performance wise (I know it doesn't make logistical sense, but it does kind of seem to null and void the importance of geom with journaling, maybe...)? A quick update; I found a bug with snapshots that held up the commit. Hopefully I will be done with it tonight. About gjournal; there would be no reason to use the two together. There may be cases where each is faster. In fact it is very likely. pjd has said he thinks suj will simply replace gjournal. GEOM itself is no less important with suj in place as it of course fills many roles. Performance testing has been done. There is no regression in softdep performance with journaling disabled. With journaling enabled there are some cases that are slightly slower. It adds an extra ordered write so any time you modify the filesystem metadata and then require it to be synchronously written to disk you may wait for an extra transaction. There are ways to further improve the performance. In fact I did some experiments that showed dbench performance nearly identical to vanilla softdep if I can resolve one wait situation. Although this is not trivial it is possible. The CPU overhead ended up being surprisingly trivial in the cases I tested. Really the extra overhead is only when doing sync writes that allocate new blocks. I am eager to see wider coverage and hear feedback from more people. I suspect for all desktop and nearly all server use it will simply be transparent. Thanks, Jeff___ 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"
