Re: Lock Order Reversal in nmount/unmount of devfs on NFS

[Doug Barton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/22/2010 11:47 AM, Kostik Belousov wrote:
| The LORs are believed to be harmless.

IMO the problem with that line of reasoning is that while any individual
LOR may be harmless there are so many harmless ones that it leads to
people either ignoring all of them, or turning off witness. I've been in
the latter category for years now.

It would be great if some effort could go into cleaning up the harmless
ones so that when a LOR happens it would actually be worth the user's
time to report it.


Doug

- -- 


Breadth of IT experience, and|   Nothin' ever doesn't change,
depth of knowledge in the DNS.   |   but nothin' changes much.
Yours for the right price.  :)   |  -- OK Go
http://SupersetSolutions.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (MingW32)

iQEcBAEBCAAGBQJMwgIrAAoJEFzGhvEaGryEPKcH/Ap1oylSMNMr5CfhX09/kMm0
7TW/nvEXqDDk/XN2bdhio/3HM/esU2Gkc0Q5zLtDPUukQzbfTlGEeuARFn2h5Ar2
SnTByZ7NFM6KP+Ksn7cNwyQ/gT71qabxVgLQ9FtxtmvBlAXKjKZ862n7Omz6qoGM
YMfESwNyUBTwRe/FxDwjImOlNXASK3Pd8lt4Gr/kyrFYJz1ooq1Biusr1mPaqJVv
7KZecaHXf2q8EmkL2mSpFk59bbuLztUduLkPGPA2/RJFvQ8Y4Jf7kg96CR1vPT7K
tCgcudnlcOCgMsUu9lpzTvW6H2Ffu4H33nJ5bVgbDLHKwxv0g3iLPgva8Q57CIw=
=g/dp
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Lock Order Reversal in nmount/unmount of devfs on NFS

[Linda Messerschmidt]

On Fri, Oct 22, 2010 at 2:47 PM, Kostik Belousov  wrote:
> The LORs are believed to be harmless.

OK, I won't worry about it.  I did check the list on
sources.zabbadoz.net and didn't see any for nfs & devfs or nfs &
syncer, so I just wanted to be sure. :)

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

Re: Lock Order Reversal in nmount/unmount of devfs on NFS

[Kostik Belousov]

On Fri, Oct 22, 2010 at 01:46:54PM -0400, Linda Messerschmidt wrote:
> When mounting a devfs filesystem on top of a directory in an NFS
> filesystem under 8.1-RELEASE-p1 r213075M, the following lock order
> reversal is reported:
> 
> lock order reversal:
>  1st 0xc264bbdc nfs (nfs) @ /usr/src/sys/kern/vfs_mount.c:1058
>  2nd 0xc264bce8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2090
> KDB: stack backtrace:
> X_db_sym_numargs(c032f02b,d58f6810,c0108c55,c00f906b,c0331eb2,...) at
> X_db_sym_numargs+0x146
> kdb_backtrace(c00f906b,c0331eb2,c22be388,c22bdd08,d58f686c,...) at
> kdb_backtrace+0x29
> witness_display_spinlock(c0331eb2,c264bce8,c0321549,c22bdd08,c033918e,...)
> at witness_display_spinlock+0x75
> witness_checkorder(c264bce8,9,c033918e,82a,0,...) at witness_checkorder+0x839
> __lockmgr_args(c264bce8,80100,c264bd04,0,0,...) at __lockmgr_args+0x7f5
> vop_stdlock(d58f6988,c01089fb,c032177a,80100,c264bc90,...) at vop_stdlock+0x62
> VOP_LOCK1_APV(c0364b00,d58f6988,c24e2824,c0395920,c264bc90,...) at
> VOP_LOCK1_APV+0xb5
> _vn_lock(c264bc90,80100,c033918e,82a,8,...) at _vn_lock+0x5e
> vget(c264bc90,80100,c24e2780,15e,c032169c,...) at vget+0xb9
> devfs_allocv(c262d280,c24c6508,d58f6a20,9d,c0508b7c,...) at devfs_allocv+0x102
> devfs_rules_apply(c24c6508,8,d58f6c40,430,0,...) at 
> devfs_rules_apply+0x14a
> vfs_donmount(c24e2780,0,c262d380,c262d380,bf7fdde9,...) at vfs_donmount+0x14c2
> nmount(c24e2780,d58f6d08,0,c,c265e2a8,...) at nmount+0x75
> syscall(d58f6d48) at syscall+0x220
> Xint0x80_syscall() at Xint0x80_syscall+0x22
> --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280e724b, esp =
> 0xbf7fddbc, ebp = 0xbf7fe318 ---
> 
> If I then try to umount the defvs, even if the unmount fails because
> the path is busy, I get a similar one:
> 
> lock order reversal:
>  1st 0xc2673488 nfs (nfs) @ /usr/src/sys/kern/vfs_mount.c:1204
>  2nd 0xc2673270 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2203
> KDB: stack backtrace:
> X_db_sym_numargs(c032f02b,d596ba48,c0108c55,c00f906b,c0331eb2,...) at
> X_db_sym_numargs+0x146
> kdb_backtrace(c00f906b,c0331eb2,c22be388,c22bdea8,d596baa4,...) at
> kdb_backtrace+0x29
> witness_display_spinlock(c0331eb2,c2673270,c033930d,c22bdea8,c033918e,...)
> at witness_display_spinlock+0x75
> witness_checkorder(c2673270,9,c033918e,89b,0,...) at witness_checkorder+0x839
> __lockmgr_args(c2673270,80100,c267328c,0,0,...) at __lockmgr_args+0x7f5
> vop_stdlock(d596bbc0,0,c033918e,80100,c2673218,...) at vop_stdlock+0x62
> VOP_LOCK1_APV(c0378cc0,d596bbc0,c00b6e03,c0395920,c2673218,...) at
> VOP_LOCK1_APV+0xb5
> _vn_lock(c2673218,80100,c033918e,89b,0,...) at _vn_lock+0x5e
> insmntque(d596bc64,c014e0ce,c2673218,0,c03389a0,...) at insmntque+0x288
> vrele(c2673218,0,c03389a0,4f9,c036dfa0,...) at vrele+0x10
> dounmount(c2677508,800,c2777a00,47e,2,...) at dounmount+0x3ce
> unmount(c2777a00,d596bd08,0,c,c27757f8,...) at unmount+0x2ff
> syscall(d596bd48) at syscall+0x220
> Xint0x80_syscall() at Xint0x80_syscall+0x22
> --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280d870f, esp =
> 0xbf7fe58c, ebp = 0xbf7fe658 ---
> 
> Both seem to occur only once per boot.  I've tried both multiply
> mounting/unmounting the same filesystem and mounting/unmounting
> multiple devfs mounts on various different NFS mounts, but I've never
> gotten more than one report for nmount and one for unmount.
> 
> It doesn't seem to hurt anything; should I bug report it?  If so, is
> there anything I can do to help with it, as far as further diagnostics
> or fixing it?
The LORs are believed to be harmless.


pgpPfHLkqeAxD.pgp
Description: PGP signature

Lock Order Reversal in nmount/unmount of devfs on NFS

[Linda Messerschmidt]

When mounting a devfs filesystem on top of a directory in an NFS
filesystem under 8.1-RELEASE-p1 r213075M, the following lock order
reversal is reported:

lock order reversal:
 1st 0xc264bbdc nfs (nfs) @ /usr/src/sys/kern/vfs_mount.c:1058
 2nd 0xc264bce8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2090
KDB: stack backtrace:
X_db_sym_numargs(c032f02b,d58f6810,c0108c55,c00f906b,c0331eb2,...) at
X_db_sym_numargs+0x146
kdb_backtrace(c00f906b,c0331eb2,c22be388,c22bdd08,d58f686c,...) at
kdb_backtrace+0x29
witness_display_spinlock(c0331eb2,c264bce8,c0321549,c22bdd08,c033918e,...)
at witness_display_spinlock+0x75
witness_checkorder(c264bce8,9,c033918e,82a,0,...) at witness_checkorder+0x839
__lockmgr_args(c264bce8,80100,c264bd04,0,0,...) at __lockmgr_args+0x7f5
vop_stdlock(d58f6988,c01089fb,c032177a,80100,c264bc90,...) at vop_stdlock+0x62
VOP_LOCK1_APV(c0364b00,d58f6988,c24e2824,c0395920,c264bc90,...) at
VOP_LOCK1_APV+0xb5
_vn_lock(c264bc90,80100,c033918e,82a,8,...) at _vn_lock+0x5e
vget(c264bc90,80100,c24e2780,15e,c032169c,...) at vget+0xb9
devfs_allocv(c262d280,c24c6508,d58f6a20,9d,c0508b7c,...) at devfs_allocv+0x102
devfs_rules_apply(c24c6508,8,d58f6c40,430,0,...) at devfs_rules_apply+0x14a
vfs_donmount(c24e2780,0,c262d380,c262d380,bf7fdde9,...) at vfs_donmount+0x14c2
nmount(c24e2780,d58f6d08,0,c,c265e2a8,...) at nmount+0x75
syscall(d58f6d48) at syscall+0x220
Xint0x80_syscall() at Xint0x80_syscall+0x22
--- syscall (378, FreeBSD ELF32, nmount), eip = 0x280e724b, esp =
0xbf7fddbc, ebp = 0xbf7fe318 ---

If I then try to umount the defvs, even if the unmount fails because
the path is busy, I get a similar one:

lock order reversal:
 1st 0xc2673488 nfs (nfs) @ /usr/src/sys/kern/vfs_mount.c:1204
 2nd 0xc2673270 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2203
KDB: stack backtrace:
X_db_sym_numargs(c032f02b,d596ba48,c0108c55,c00f906b,c0331eb2,...) at
X_db_sym_numargs+0x146
kdb_backtrace(c00f906b,c0331eb2,c22be388,c22bdea8,d596baa4,...) at
kdb_backtrace+0x29
witness_display_spinlock(c0331eb2,c2673270,c033930d,c22bdea8,c033918e,...)
at witness_display_spinlock+0x75
witness_checkorder(c2673270,9,c033918e,89b,0,...) at witness_checkorder+0x839
__lockmgr_args(c2673270,80100,c267328c,0,0,...) at __lockmgr_args+0x7f5
vop_stdlock(d596bbc0,0,c033918e,80100,c2673218,...) at vop_stdlock+0x62
VOP_LOCK1_APV(c0378cc0,d596bbc0,c00b6e03,c0395920,c2673218,...) at
VOP_LOCK1_APV+0xb5
_vn_lock(c2673218,80100,c033918e,89b,0,...) at _vn_lock+0x5e
insmntque(d596bc64,c014e0ce,c2673218,0,c03389a0,...) at insmntque+0x288
vrele(c2673218,0,c03389a0,4f9,c036dfa0,...) at vrele+0x10
dounmount(c2677508,800,c2777a00,47e,2,...) at dounmount+0x3ce
unmount(c2777a00,d596bd08,0,c,c27757f8,...) at unmount+0x2ff
syscall(d596bd48) at syscall+0x220
Xint0x80_syscall() at Xint0x80_syscall+0x22
--- syscall (22, FreeBSD ELF32, unmount), eip = 0x280d870f, esp =
0xbf7fe58c, ebp = 0xbf7fe658 ---

Both seem to occur only once per boot.  I've tried both multiply
mounting/unmounting the same filesystem and mounting/unmounting
multiple devfs mounts on various different NFS mounts, but I've never
gotten more than one report for nmount and one for unmount.

It doesn't seem to hurt anything; should I bug report it?  If so, is
there anything I can do to help with it, as far as further diagnostics
or fixing it?

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

Re: Tested wanted: BSD-licensed libgcc replacement, libcompiler_rt

[Ed Schouten]

* Ed Schouten , 20101022 16:30:
> - Rebuild all your software (yes, I know it's unfortunate).

Right after I sent this, I thought I'd better clarify this. You don't
need to rebuild your software. This change will not break the existing
ABI. This step is just mentioned here, since libgcc.a is statically
linked into applications. Simply rebuilding and reinstall world is not
sufficient to make 3rd party applications use this.

-- 
 Ed Schouten 
 WWW: http://80386.nl/


pgpbcBir7S44Y.pgp
Description: PGP signature

Tested wanted: BSD-licensed libgcc replacement, libcompiler_rt

[Ed Schouten]

Hello everyone,

At EuroBSDCon I was talking with some committers active in the area of
Clang (brooks, kwm, others) about replacing our libgcc shipped with GCC
4.2.1 with a BSD-licensed version. The LLVM folks have a BSD licensed
implementation called libcompiler_rt. See:

http://compiler-rt.llvm.org/

Right now it is already complete enough to replace libgcc.a and
libgcc_p.a (mostly math rountines), but it doesn't yet implement the
functionality (e.g. unwinder) to replace libgcc_eh.a, libgcc_eh_p.a and
libgcc_s.so.1.

I've created a branch in Subversion which replaces libgcc.a and
libgcc_p.a with libcompiler_rt.a and libcompiler_rt_p.a and symlinks it
to the original names. It seems to survive a `make universe' and it
works properly on at least amd64. Right now the only issue I can think
of, is that __clear_cache() is broken on ARM, but that can be fixed
trivially.

My plan would be to commit this work to HEAD by the end of November (1
month from now), but it would be nice if it could get some more testing
in the mean time, especially on non-x86 architectures.

How to test this:

- Check out the branch from SVN:
svn co svn://svn.freebsd.org/base/user/ed/compiler-rt/
- Rebuild and reinstall world (and kernel).
- Rebuild all your software (yes, I know it's unfortunate).
- See whether software crashes or misbehaves, while it didn't do that
  previously.

In the mean time, I'll see if I can get the Ports folks to run an
exp-run with this branch, which should already give some coverage.

Thanks!

-- 
 Ed Schouten 
 WWW: http://80386.nl/


pgpxtVH6ehp5C.pgp
Description: PGP signature

Re: Summary: Re: Spin down HDD after disk sync or before power off

[Bruce Cran]

On Fri, 22 Oct 2010 12:07:36 +0200
Tijl Coosemans  wrote:

> FreeBSD frequently accesses hard disks (log files, flushing dirty
> memory pages every 30s,...) and laptop drives tend to have aggressive
> power saving settings by default. That's why your load cycle is so
> high.

I'm not sure the APM value updates the idle3 timer inside the
drive: it may be necessary to run WD's wdidle3.exe tool to change the
power management timer.  And yes, people are rather annoyed that it's
necessary to have a copy of DOS to update the drive!

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

Re: Summary: Re: Spin down HDD after disk sync or before power off

[Tijl Coosemans]

On Friday 22 October 2010 00:32:54 Paul Wootton wrote:
> Actually, the green series does spin all the way down, well at least
> the drive I have does.
> Here is the output from one of my drives, that I do not think has
> long left to live.
> 
> === START OF INFORMATION SECTION ===
> Model Family: Western Digital Caviar Green family
> Device Model: WDC WD5000AADS-00M2B0
> Serial Number:WD-WMAV51882791
> Firmware Version: 01.00A01
> User Capacity:500,107,862,016 bytes
> Device is:In smartctl database [for details use: -P show]
> ATA Version is:   8
> ATA Standard is:  Exact ATA specification draft version not indicated
> Local Time is:Thu Oct 21 23:31:35 2010 BST
> SMART support is: Available - device has SMART capability.
> SMART support is: Enabled
> 
> SMART Attributes Data Structure revision number: 16
> Vendor Specific SMART Attributes with Thresholds:
> ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE  
> UPDATED  WHEN_FAILED RAW_VALUE
>1 Raw_Read_Error_Rate 0x002f   200   200   051Pre-fail  
> Always   -   0
>3 Spin_Up_Time0x0027   111   104   021Pre-fail  
> Always   -   7425
>4 Start_Stop_Count0x0032   100   100   000Old_age   
> Always   -   98
>5 Reallocated_Sector_Ct   0x0033   200   200   140Pre-fail  
> Always   -   0
>7 Seek_Error_Rate 0x002e   100   253   000Old_age   
> Always   -   0
>9 Power_On_Hours  0x0032   093   093   000Old_age   
> Always   -   5295
>   10 Spin_Retry_Count0x0032   100   253   000Old_age   
> Always   -   0
>   11 Calibration_Retry_Count 0x0032   100   253   000Old_age   
> Always   -   0
>   12 Power_Cycle_Count   0x0032   100   100   000Old_age   
> Always   -   96
> 192 Power-Off_Retract_Count 0x0032   200   200   000Old_age   
> Always   -   95
> 193 Load_Cycle_Count0x0032   001   001   000Old_age   
> Always   -   781014
> 194 Temperature_Celsius 0x0022   120   102   000Old_age   
> Always   -   27
> 196 Reallocated_Event_Count 0x0032   200   200   000Old_age   
> Always   -   0
> 197 Current_Pending_Sector  0x0032   200   200   000Old_age   
> Always   -   0
> 198 Offline_Uncorrectable   0x0030   200   200   000Old_age   
> Offline  -   0
> 199 UDMA_CRC_Error_Count0x0032   200   200   000Old_age   
> Always   -   0
> 200 Multi_Zone_Error_Rate   0x0008   200   200   000Old_age   
> Offline  -   0
> 
> 
> The datasheet for these drive 
> http://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-701229.pdf
>  
> says
> "Reliability/Data Integrity
> Load/unload cycles (3) 300,000
> Limited Warranty (years) (4)
> (3) Controlled unload at ambient condition
> (4) The term of the limited warranty my vary by region"
> 
> Also 
> http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqid=5357
> "(drive has been validated to 1 million load/unload cycles without issue)"
> 
> Im already at 781014 load cycles, yet the drive is only about 7 months 
> old. Doing the math, I am getting a load/unload cycle about every 24.5 
> seconds
> Another 2 months and I will be knocking on for 1 million load/unload 
> cycles
> 
> As DES has already said, for most people the extra load/unload cycles 
> when rebooting a computer will not be an issue at all and is far more 
> desirable than an emergency park when powering down

FreeBSD frequently accesses hard disks (log files, flushing dirty
memory pages every 30s,...) and laptop drives tend to have aggressive
power saving settings by default. That's why your load cycle is so high.

To deal with this you should consider installing sysutils/ataidle and
adding these lines to /etc/rc.conf:

ataidle_enable="YES"
ataidle_devices="ad0"
ataidle_ad0="-P 0"

An alternative is to use atacontrol(8).

If you don't mind the spin down when rebooting you can solve the
emergency park at shutdown with a simple patch like this:

--- sys/dev/ata/ata-disk.c
+++ sys/dev/ata/ata-disk.c
@@ -193,6 +193,8 @@
 
 if (atadev->param.support.command2 & ATA_SUPPORT_FLUSHCACHE)
 ata_controlcmd(dev, ATA_FLUSHCACHE, 0, 0, 0);
+if (atadev->param.support.command1 & ATA_SUPPORT_POWERMGT)
+ata_controlcmd(dev, ATA_STANDBY_IMMEDIATE, 0, 0, 0);
 return 0;
 }
 


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

Re: Summary: Re: Spin down HDD after disk sync or before power off

[Alexander Best]

On Fri Oct 22 10, Alexander Motin wrote:
> Alexander Best wrote:
> > the current implementation (kern.cam.power_down) uses a singe "sleep"
> > operation, whereas the patch by oliver uses "flush" and "standby immediate".
> 
> Sleep is just more aggressive. It puts device into deeper sleep state. I
> don't think it is important from wearing point of view.
> 
> > unfortunately almost nobody was aware of mav's work at the time of the
> > discussion. would have been nice to have a note in cam(4) explaining the
> > purpose of kern.cam.power_down. that way a lot of double work could have 
> > been
> > avoided.
> 
> That code was expected to handle spindown on shutdown in unified fashion
> for ATA and SCSI devices without dependency from peripheral driver (even
> without one), just using different commands for each protocol. It works,
> but in current implementation it is unreliable. The problem is that it
> uses polled operation mode, not supported by some controllers or
> unreliable on some (e.g. atapicam). So the code is disabled now by
> default. I haven't yet decided it's future: it should be either reworked
> or reverted.

so how about olivers patch? it will only apply to ata devices so it's
garanteed not to break any other CAM devices (i'm thinking about the aac
controller issue). you could revert your previous shutdown work and plug
olivers patch into CAM. you might want to replace the combination of
flush/standby immediate with sleep.

cheers.
alex

> 
> As positive side -- as soon as CAM is not using NewBus at the moment,
> CAM registers own shutdown handlers. That allows CAM to receive the
> howto argument, which allows to separate cases of reboot and shutdown
> cases just by:
>   if ((howto & RB_POWEROFF) == 0)
> 
> > is the ATA(4) subsystem still being actively worked on or will it die out 
> > after
> > officially switching to ATA_CAM? the question is, if it is worth 
> > implementing
> > hdd spin down for ATA(4)?
> 
> I don't think it will be really critical. Next months I am going to work
> on ataraid(4) replacement, which was main declared show stopper for the
> switch. I hope to trash legacy code some time after switching to ATA_CAM
> to clear number of odd things (like almost not working port multipliers
> support or duplicate drivers), required by it.
> 
> -- 
> Alexander Motin

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

Re: Deterministic builds?

[Ulrich Spörlein]

On Thu, 21.10.2010 at 21:50:26 +0200, Erik Cederstrand wrote:
> Den 21/10/2010 kl. 19.57 skrev Ulrich Spörlein:
> > On Mon, 11.10.2010 at 11:35:42 +0200, Erik Cederstrand wrote:
> >> I'm beginning to think that it should at least be optional. Removing e.g. 
> >> build times, mtimes and path to OBJDIR or SRCDIR might not make everyone 
> >> happy.
> > 
> > The problem with making it optional is, that we already have enough
> > flags and knobs. No need in adding more.
> > 
> > Besides, why would people want to know the date of the build? Far more
> > important is the date and state of the source for the time of build. So
> > you might want to replace ${BUILDATE} with ${SRCDATE} somehow (time of
> > last commit?).
> > 
> > Otherwise, please go for it. It would be nice if two people compiling
> > GENERIC for the same source-base would get identical binaries.
> 
> It goes without saying that I agree with you on this. But it seems the 
> feature will require fairly invasive changes to a standard FreeBSD, e.g. 
> changing standard ar behavior, and building kernels and some other tools 
> without debugging symbols. I'm not experienced enough to determine if this is 
> fine with the majority of users, but hiding the changes under a knob would at 
> least let the feature prove itself and put off bikeshedding for a while. If 
> the project works out, we can discuss changing the default.
> 
> I'm still not sure what to do with debugging symbols. Currently absolute 
> paths to source files are used. I would like to change that to absolute paths 
> , i.e. usr.bin/ar/ar.c. That might even be beneficial if someone is debugging 
> the binary on a system that doesn't have the source tree located in 
> /some/obscure/directory/src. It's my understanding that gdb uses the path to 
> look up source code related to stack traces etc. It seems gdb can handle 
> relative paths, but I have no idea if it actually works, or if it's a 
> nuisance to use compared to absolute paths. Any hints?

Why do you make this a requirement? Of course it's usually easier to
build different releases from different source directories, but I think
requiring the following conditions are fine:

1. If you build a specific svn revision,
2. sitting in /usr/src with
3. the default make.conf (ie., no special flags, no frobbing of OBJDIR)
4. at different times

then you get the same binaries.

Let's start with an achievable, not-so-intrusive goal, right? :)

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

Re: Summary: Re: Spin down HDD after disk sync or before power off

[Alexander Motin]

Alexander Best wrote:
> the current implementation (kern.cam.power_down) uses a singe "sleep"
> operation, whereas the patch by oliver uses "flush" and "standby immediate".

Sleep is just more aggressive. It puts device into deeper sleep state. I
don't think it is important from wearing point of view.

> unfortunately almost nobody was aware of mav's work at the time of the
> discussion. would have been nice to have a note in cam(4) explaining the
> purpose of kern.cam.power_down. that way a lot of double work could have been
> avoided.

That code was expected to handle spindown on shutdown in unified fashion
for ATA and SCSI devices without dependency from peripheral driver (even
without one), just using different commands for each protocol. It works,
but in current implementation it is unreliable. The problem is that it
uses polled operation mode, not supported by some controllers or
unreliable on some (e.g. atapicam). So the code is disabled now by
default. I haven't yet decided it's future: it should be either reworked
or reverted.

As positive side -- as soon as CAM is not using NewBus at the moment,
CAM registers own shutdown handlers. That allows CAM to receive the
howto argument, which allows to separate cases of reboot and shutdown
cases just by:
if ((howto & RB_POWEROFF) == 0)

> is the ATA(4) subsystem still being actively worked on or will it die out 
> after
> officially switching to ATA_CAM? the question is, if it is worth implementing
> hdd spin down for ATA(4)?

I don't think it will be really critical. Next months I am going to work
on ataraid(4) replacement, which was main declared show stopper for the
switch. I hope to trash legacy code some time after switching to ATA_CAM
to clear number of odd things (like almost not working port multipliers
support or duplicate drivers), required by it.

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

Re: kmod if_alc in 8-CURRENT

[Matthias Apitz]

El día Friday, October 22, 2010 a las 09:14:03AM +0200, Matthias Apitz escribió:

> # make
> Warning: Object directory not changed from original
> /usr/src/sys/modules/alc
> cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
> -nostdinc   -I. -I@ -I@/contrib/altq -finli
> ne-limit=8000 --param inline-unit-growth=100 --param
> large-function-growth=1000 -fno-common  -mno-align-long
> -strings -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse
> -mno-sse2 -mno-sse3 -ffreestanding -fsta
> ck-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls
> -Wnested-externs -Wstrict-prototype
> s  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
> -Wno-pointer-sign -fformat-extensions 
> -c /usr/src/sys/modules/alc/../../dev/alc/if_alc.c
> cc1: warnings being treated as errors
> /usr/src/sys/modules/alc/../../dev/alc/if_alc.c: In function
> 'alc_rxfilter':
> /usr/src/sys/modules/alc/../../dev/alc/if_alc.c:3465: warning: implicit
> declaration of function 'if_maddr_rl
> ock'
> /usr/src/sys/modules/alc/../../dev/alc/if_alc.c:3465: warning: nested
> extern declaration of 'if_maddr_rlock'
> /usr/src/sys/modules/alc/../../dev/alc/if_alc.c:3473: warning: implicit
> declaration of function 'if_maddr_ru
> nlock'
> /usr/src/sys/modules/alc/../../dev/alc/if_alc.c:3473: warning: nested
> extern declaration of 'if_maddr_runloc
> k'
> *** Error code 1

The change was introduced with rev. 1.2 of the driver:

revision 1.2
date: 2009/06/26 11:45:06;  author: rwatson;  state: Exp;  lines: +2 -2
SVN rev 195049 on 2009-06-26 11:45:06Z by rwatson

Use if_maddr_rlock()/if_maddr_runlock() rather than IF_ADDR_LOCK()/
IF_ADDR_UNLOCK() across network device drivers when accessing the
per-interface multicast address list, if_multiaddrs.  This will
allow us to change the locking strategy without affecting our driver
programming interface or binary interface.

and I checked out RELENG_8_0_0_RELEASE (revision: 1.3.2.2.2.1)

will Cc: the author to see what I should do with my 8-CURRENT from May
2009 to get support for this NIC;

Thanks

matthias

-- 
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e  - w http://www.unixarea.de/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: kmod if_alc in 8-CURRENT

[Matthias Apitz]

El día Thursday, October 21, 2010 a las 08:44:32PM +0200, Paul B Mahol escribió:

> On 10/21/10, Matthias Apitz  wrote:
> > El dia Thursday, October 21, 2010 a las 08:35:09PM +0200, Paul B Mahol
> > escribio:
> >
> >> > # cd /usr/src
> >> > # make buildkernel KERNCONF=GENERIC
> >> >
> >> > does not build the module if_alc.ko
> >> >
> >> > What I'm missing? Or what is the correct way to get this module for my
> >> > kernel level?
> >>
> >> /sys/modules/alc
> >
> > Yes, thanks. I realized this some hours ago and CVS up this too, but
> > the module does not get build.
> 
> Because you did not have Makefiles of higher directories.
> 
> Anyway:
> 
> # cd /sys/modules/alc && make install clean
> 
> Should do it.

Thanks, but:

# make
Warning: Object directory not changed from original
/usr/src/sys/modules/alc
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
-nostdinc   -I. -I@ -I@/contrib/altq -finli
ne-limit=8000 --param inline-unit-growth=100 --param
large-function-growth=1000 -fno-common  -mno-align-long
-strings -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse
-mno-sse2 -mno-sse3 -ffreestanding -fsta
ck-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototype
s  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
-Wno-pointer-sign -fformat-extensions 
-c /usr/src/sys/modules/alc/../../dev/alc/if_alc.c
cc1: warnings being treated as errors
/usr/src/sys/modules/alc/../../dev/alc/if_alc.c: In function
'alc_rxfilter':
/usr/src/sys/modules/alc/../../dev/alc/if_alc.c:3465: warning: implicit
declaration of function 'if_maddr_rl
ock'
/usr/src/sys/modules/alc/../../dev/alc/if_alc.c:3465: warning: nested
extern declaration of 'if_maddr_rlock'
/usr/src/sys/modules/alc/../../dev/alc/if_alc.c:3473: warning: implicit
declaration of function 'if_maddr_ru
nlock'
/usr/src/sys/modules/alc/../../dev/alc/if_alc.c:3473: warning: nested
extern declaration of 'if_maddr_runloc
k'
*** Error code 1

matthias

-- 
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e  - w http://www.unixarea.de/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"