Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking

2013-10-06 Thread Alexander Motin

On 02.10.2013 20:30, John Baldwin wrote:

On Saturday, September 07, 2013 2:32:45 am Alexander Motin wrote:

On 07.09.2013 02:02, Jeremie Le Hen wrote:

On Fri, Sep 06, 2013 at 11:29:11AM +0300, Alexander Motin wrote:

On 06.09.2013 11:06, Jeremie Le Hen wrote:

On Fri, Sep 06, 2013 at 12:46:27AM +0200, Olivier Cochard-Labbé wrote:

On Thu, Sep 5, 2013 at 11:38 PM, Alexander Motin 

wrote:

I've found and fixed possible double request completion, that could

cause

such symptoms if happened. Updated patch located as usual:
http://people.freebsd.org/~mav/camlock_patches/camlock_20130905.patch


With this new one I cannot boot any more (I also updated the source
tree).  This is a hand transcripted version:

Trying to mount root from zfs:zroot/root []...
panic: Batch flag already set
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper()
kdb_backtrace()
vpanic()
kassert_panic()
xpt_batch_start()
ata_interrupt()
softclock_call_cc()
softclock()
ithread_loop()
fork_exit()
fork_trampoline()


Thank you for the report. I see my fault. It is probably specific to
ata(4) driver only. I've workarounded that in new patch version, but
probably that area needs some rethinking.

http://people.freebsd.org/~mav/camlock_patches/camlock_20130906.patch


I'm not sure you needed a confirmation, but it boots.  Thanks :).

I didn't quite understand the thread; is direct dispatch enabled for
amd64?  ISTR you said only i386 but someone else posted the macro for
amd64.


Yes, it is enabled for amd64. I've said x86, meaning both i386 and amd64.


FYI, I tested mfi with this patch set and mfid worked fine for handling g_up
directly:

Index: dev/mfi/mfi_disk.c
===
--- dev/mfi/mfi_disk.c  (revision 257407)
+++ dev/mfi/mfi_disk.c  (working copy)
@@ -162,6 +162,7 @@
 sc->ld_disk->d_unit = sc->ld_unit;
 sc->ld_disk->d_sectorsize = secsize;
 sc->ld_disk->d_mediasize = sectors * secsize;
+   sc->ld_disk->d_flags = DISKFLAG_DIRECT_COMPLETION;
 if (sc->ld_disk->d_mediasize >= (1 * 1024 * 1024)) {
 sc->ld_disk->d_fwheads = 255;
 sc->ld_disk->d_fwsectors = 63;



Thank you for the feedback. But looking on mfi driver sources I would 
say that it calls biodone() from mfi_disk_complete() from cm_complete() 
method, which is called while holding mfi_io_lock mutex. I guess that if 
on top of mfi device would be some GEOM class, supporting direct 
dispatch and sending new requests down on previous request completion 
(or retrying requests), that could cause recursive mfi_io_lock 
acquisition. That is exactly the cause why I've added this flag. May be 
it is a bit paranoid, but it is better to be safe then sorry.


Another good reason to drop the lock before calling biodone() would be 
reducing the lock hold time. Otherwise it may just increase lock 
congestion there and destroy all benefits of the direct dispatch.


--
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: Call for FreeBSD 2013Q3 (July-September) Status Reports

2013-10-06 Thread Gabor Pali
Dear FreeBSD Community,

This is another gentle reminder that the deadline for submissions for
the third Quarterly Status Report is tomorrow!  Please find the
details quoted below.

On Sun, Sep 29, 2013 at 12:22 PM, Gabor Pali  wrote:
> Dear FreeBSD Community,
>
> Please note that the next submission date for the July to September
> Quarterly Status Reports is October 7th, 2013, bit more than a week
> away.  Please consult my previous message for the details:
>
> On Mon, Sep 9, 2013 at 12:04 AM, Gabor Pali  wrote:
>> They do not have to be very long -- basically they may be about
>> anything that lets people know what is going on around the FreeBSD
>> Project.  Submission of reports is not restricted to committers:
>> Anyone who is doing anything interesting and FreeBSD-related can (and
>> therefore encouraged to) write one!
>>
>> The preferred and easiest submission method is to use the XML
>> generator [1] with the result emailed as an attachment to us, that is,
>> mont...@freebsd.org [2].  There is also an XML template [3] which can
>> be filled out manually and attached if preferred.
>>
>> To enable compilation and publication of the Q3 report as soon as
>> possible for the October 7th deadline, please be prompt with any
>> report submissions you may have.
>>
>> We are looking forward to all of your 2013Q3 reports!
>>
>> Cheers,
>> Gabor
>>
>>
>> [1] http://www.freebsd.org/cgi/monthly.cgi
>> [2] mailto:mont...@freebsd.org
>> [3] http://www.freebsd.org/news/status/report-sample.xml
___
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"


amdtemp need help with testing

2013-10-06 Thread rozhuk . im
I updated amdtemp and now I need your help with testing.

Now the driver should support all AMD processors.
For a family of 15h and 16h, not all sensors are available - for my system
does not find drivers for ati SMBus, and other systems based on the AMD I
have not.


/*-
 * Copyright (c) 2008, 2009 Rui Paulo 
 * Copyright (c) 2009 Norikatsu Shigemura 
 * Copyright (c) 2009-2011 Jung-uk Kim 
 * Copyright (c) 2013 Rozhuk Ivan 
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
 * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
 * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
 * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
 * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
 * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
 * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
 * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 * POSSIBILITY OF SUCH DAMAGE.
 */

/*
 * Driver for the AMD CPU on-die thermal sensors.
 * Initially based on the k8temp Linux driver.
 */

#include 
__FBSDID("$FreeBSD$");

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 

#include 

#if defined(__FreeBSD_version) && (__FreeBSD_version < 99)
/* XXX */
extern uint32_t pci_cfgregread(int, int, int, int, int);
#endif


struct amdtemp_softc {
device_tdev;
struct mtx  lock; /* Read/write lock for some registers. */
uint32_tcpu_ncores;
uint32_tflags;
uint32_ttts_flags; /* Thermaltrip Status flags. */
int32_t tts_temp_offset[4];
int32_t rtc_temp_offset;
int32_t tsi_temp_offset[8];
struct sysctl_oid   *sysctl_cpu[MAXCPU]; /* dev.cpu.X.temperature 
oids. */
struct intr_config_hook sc_ich;
};
#define AMDTEMP_F_TTS   1   /* Thermaltrip Status. */
#define AMDTEMP_F_RTC   2   /* Reported Temperature Control. */
#define AMDTEMP_F_TSI   4   /* TSI via CPU registers. */
#define AMDTEMP_F_SBTSI 8   /* TSI via SMBus. */

#define AMDTEMP_TTS_F_CS_SWAP   0x01/* ThermSenseCoreSel is inverted. */
#define AMDTEMP_TTS_F_CT_10BIT  0x02/* CurTmp is 10-bit wide. */
#define AMDTEMP_TTS_F_OFF28 0x04/* CurTmp starts at -28C. */


#define AMDTEMP_LOCK(sc)mtx_lock(&(sc)->lock)
#define AMDTEMP_UNLOCK(sc)  mtx_unlock(&(sc)->lock)


/* CPU Family/Model Register */
#define AMD_REG_CPUID   0xfc

/* 
 * Thermaltrip Status Register
 * BIOS and Kernel Developer’s Guide for AMD NPT Family 0Fh Processors
 * 32559 Rev. 3.16 November 2009
 */
/* D18F3xE4 Thermtrip Status Register */
#define AMD_REG_THERMTRIP_STAT  0xe4
union reg_amd_thermtrip_status_desc {
uint32_t u32;
struct reg_amd_thermtrip_status_bits {
uint32_t r0:1;  /* 0 Reserved. */
uint32_t Thermtp:1; /* 1 ro The processor has entered the 
THERMTRIP state. */
uint32_t ThermSenseCoreSel:1; /* 2 rw  */
uint32_t ThermtpSense0:1; /* 3 ro  */
uint32_t ThermtpSense1:1; /* 4 ro  */
uint32_t ThermtpEn:1;   /* 5 ro The THERMTRIP state is 
supported by the processor. */
uint32_t ThermSenseSel:1; /* 6 rw  */
uint32_t r1:1;  /* 7 Reserved. */
uint32_t DiodeOffset:6; /* 13:8 ro Thermal diode offset is used 
to correct the measurement made by an external temperature sensor. */
uint32_t CurTmp:10; /* 23:14 ro This field returns the 
current value of the internal thermal sensor. */
uint32_t TjOffset:5;/* 28:24 ro This field is the offset 
from CurTmp used to normalize to Tcontrol. */
uint32_t r2:2;  /* 30:29 Reserved. */
uint32_t SwThermtp:1;   /* 31 rw  */
} __packed bits;
};


/* DRAM Configuration High Register */
#define AMD_REG_DRAM_CONF_HIGH  0x94/* Function 2 */
#define AMD_REG_DRAM_MODE_DDR3  0x0100

/* D18F3xA4 Reported Temperature Control R