On Tue, May 24, 2016 at 21:59:53 +0700, Alex V. Petrov wrote:
> 24.05.16 20:21, Kenneth D. Merry ??:
> > On Tue, May 24, 2016 at 08:04:21 +0300, Oleg V. Nauman wrote:
> >> On Monday 23 May 2016 19:08:16 Kenneth D. Merry wrote:
> >>> On Tue, May 24, 2016 at
On Tue, May 24, 2016 at 23:54:09 +0300, Oleg V. Nauman wrote:
> On Tuesday 24 May 2016 16:17:33 you wrote:
> > Okay, I've got a basic idea of what may be going on. The resets that are
> > getting sent are triggering another probe, which then triggers a reset,
> > which triggers a probe...and so on
On Wed, May 25, 2016 at 07:35:06 +0700, Alex V. Petrov wrote:
>
>
> 25.05.16 03:18, Kenneth D. Merry ??:
> > On Tue, May 24, 2016 at 21:59:53 +0700, Alex V. Petrov wrote:
> >> 24.05.16 20:21, Kenneth D. Merry ??:
> >>> On Tue, May 24, 2016 at
On Wed, May 25, 2016 at 14:36:59 +0200, Gary Jennejohn wrote:
> On Wed, 25 May 2016 08:15:11 +0200
> Gary Jennejohn wrote:
>
> > On Tue, 24 May 2016 15:10:41 -0400
> > "Kenneth D. Merry" wrote:
> >
> > > Can you send full dmesg output from the wo
On Thu, May 26, 2016 at 08:42:53 +0200, Gary Jennejohn wrote:
> Now that ken@ has checked in the SMR code I'm wondering how I can see
> whether it's having any effect.
>
> I have a 8TB SMR disk in a USB3 enclosure. Does the kernel emit any
> sort of trace to indicate that it sees the drive as SMR
On Thu, May 26, 2016 at 15:29:21 +0200, Gary Jennejohn wrote:
> On Thu, 26 May 2016 08:34:45 -0400
> "Kenneth D. Merry" wrote:
>
> > On Thu, May 26, 2016 at 08:42:53 +0200, Gary Jennejohn wrote:
> > What kind of drive is it?
> >
>
> ST8000AS 0
On Thu, May 26, 2016 at 16:00:41 +0200, Gary Jennejohn wrote:
> On Thu, 26 May 2016 09:41:20 -0400
> "Kenneth D. Merry" wrote:
>
> > On Thu, May 26, 2016 at 15:29:21 +0200, Gary Jennejohn wrote:
> > > On Thu, 26 May 2016 08:34:45 -0400
> > > "K
On Thu, May 26, 2016 at 15:02:24 +0100, Igor Mozolevsky wrote:
> On 26 May 2016 at 14:41, Kenneth D. Merry wrote:
>
> > On Thu, May 26, 2016 at 15:29:21 +0200, Gary Jennejohn wrote:
> > > On Thu, 26 May 2016 08:34:45 -0400
> > > "Kenneth D. Merry" wrote:
On Thu, May 26, 2016 at 16:42:10 +0200, Gary Jennejohn wrote:
> On Thu, 26 May 2016 10:10:14 -0400
> "Kenneth D. Merry" wrote:
>
> > On Thu, May 26, 2016 at 16:00:41 +0200, Gary Jennejohn wrote:
> > > protocol ATA/ATAPI-9 SATA 3.x
> > >
Ken
- Forwarded message from "Kenneth D. Merry" -
Date: Tue, 21 Jun 2016 20:18:19 +0000 (UTC)
From: "Kenneth D. Merry"
To: src-committ...@freebsd.org, svn-src-...@freebsd.org,
svn-src-h...@freebsd.org
Subject: svn commit: r302069 - head/sys/geom
Author: ken
Date: Tue
On Sun, Jun 04, 2017 at 09:52:36 +0200, Hans Petter Selasky wrote:
> On 06/04/17 09:39, Tomoaki AOKI wrote:
> > Hi
> >
> > One possibility would be to make it MD build-time OTIONS,
> > defaulting 1M on regular systems and 128k on smaller systems.
> >
> > Of course I guess making it a tunable (or
On Sat, Sep 24, 2011 at 21:27:22 +0200, Fabian Keil wrote:
> "Kenneth D. Merry" wrote:
>
> > I have attached a set of patches against head that implement SCSI
> > descriptor sense support for CAM.
>
> > Anyway, I'd appreciate any testing and feedback o
On Tue, Sep 27, 2011 at 21:46:03 +0200, Fabian Keil wrote:
> "Kenneth D. Merry" wrote:
>
> > On Sat, Sep 24, 2011 at 21:27:22 +0200, Fabian Keil wrote:
> > > "Kenneth D. Merry" wrote:
> > >
> > > > I have attached a set of pat
This has been committed to head, and the plan is to get it into stable/9
in time for 9.0.
Please let me know if you run into any problems with the changes.
Thanks,
Ken
On Fri, Sep 30, 2011 at 23:19:14 -0600, Kenneth D. Merry wrote:
>
> I have attached a new version of the patches,
The CAM Target Layer (CTL) is now available for testing. I am planning to
commit it to to head next week, barring any major objections.
CTL is a disk and processor device emulation subsystem originally written
for Copan Systems under Linux starting in 2003. It has been shipping in
Copan (now SG
The CAM Target Layer (CTL) is now available for testing. I am planning to
commit it to to head next week, barring any major objections.
CTL is a disk and processor device emulation subsystem originally written
for Copan Systems under Linux starting in 2003. It has been shipping in
Copan (now SG
On Thu, Jan 05, 2012 at 01:03:57 -0800, Julian Elischer wrote:
> On 1/4/12 8:39 PM, Kenneth D. Merry wrote:
> >The CAM Target Layer (CTL) is now available for testing. I am planning to
> >commit it to to head next week, barring any major objections.
> >
> >CTL is
On Wed, Jan 04, 2012 at 21:53:11 -0700, Kenneth D. Merry wrote:
>
> The CAM Target Layer (CTL) is now available for testing. I am planning to
> commit it to to head next week, barring any major objections.
>
> CTL is a disk and processor device emulation subsystem originally writ
On Thu, Jan 12, 2012 at 14:59:11 -0600, Dan McGregor wrote:
> Building world with clang now (as of r229997) no longer compiles because
> ctlstat was imported into the tree. The error is:
>
> clang -O2 -pipe -I/usr/src/usr.bin/ctlstat/../../sys -std=gnu99
> -fstack-protector -Wsystem-headers -Wer
The LSI-supported version of the mps(4) driver that supports their 6Gb SAS
HBAs as well as WarpDrive controllers, is available here:
http://people.freebsd.org/~ken/lsi/mps_lsi.20120120.1.txt
I plan to check it in to head next week, and then MFC it into stable/9 a
week after that most likely.
Pl
On Fri, Jan 20, 2012 at 12:53:04 -0800, Freddie Cash wrote:
> On Fri, Jan 20, 2012 at 12:44 PM, Kenneth D. Merry wrote:
> > The LSI-supported version of the mps(4) driver that supports their 6Gb SAS
> > HBAs as well as WarpDrive controllers, is available here:
>
> Just
On Fri, Jan 20, 2012 at 23:14:20 -, Steven Hartland wrote:
> - Original Message -
> From: "Kenneth D. Merry"
> To: ;
> Sent: Friday, January 20, 2012 8:44 PM
> Subject: LSI supported mps(4) driver available
>
>
> >
> >The LSI-supported
On Sun, Jan 22, 2012 at 20:52:38 -0600, Richard Todd wrote:
> Hi. I tried upgrading my amd64 10-CURRENT box to the most recent -CURRENT
> code
> and found that the new kernel couldn't find my two disks and tape drive that
> are on a Firewire bus. All the USB and AHCI-attached hardware still show
On Tue, Jan 24, 2012 at 00:03:56 -0600, Richard Todd wrote:
> On Mon, Jan 23, 2012 at 11:16:05AM -0700, Kenneth D. Merry wrote:
> > If you can, please try the attached patch and see if it has any impact on
> > the problem. There is a bug in that commit in that we shouldn't be
On Wed, Jan 25, 2012 at 20:47:37 -0800, Dennis Glatting wrote:
> On Fri, 2012-01-20 at 13:44 -0700, Kenneth D. Merry wrote:
> > The LSI-supported version of the mps(4) driver that supports their 6Gb SAS
> > HBAs as well as WarpDrive controllers, is available here
On Tue, Feb 07, 2012 at 21:00:28 +0530, Desai, Kashyap wrote:
> Can you to reproduce issue with below mentioned changes..
>
> In mps.c
>
> mps_get_tunables(struct mps_softc *sc)
> {
> char tmpstr[80];
>
> /* XXX default to some debugging for now */
> sc->mps_debug = MPS_FAULT;
>
>
On Tue, Mar 27, 2012 at 23:50:31 +1030, Matt Thyer wrote:
> On 26 March 2012 23:55, Gary Palmer wrote:
>
> > On Mon, Mar 26, 2012 at 08:05:59PM +1030, Matt Thyer wrote:
> > > On Mar 26, 2012 3:43 AM, "Garrett Cooper" wrote:
> > > >
> > > > On Sun, Mar 25, 2012 at 5:16 AM, Matt Thyer
> > wrote:
Hi folks,
I have attached some patches that fix an object lifetime issue between CAM
and GEOM.
Fixing the bug required adding a callback to the GEOM disk code, and adding
a callback that a GEOM class can register to get notified when a provider
is destroyed.
The probable commit message is below.
On Thu, Jun 21, 2012 at 19:53:03 +0400, Andrey V. Elsukov wrote:
> On 21.06.2012 08:29, Kenneth D. Merry wrote:
> > Fix a bug which causes a panic in daopen(). The panic is caused by
> > a da(4) instance going away while GEOM is still probing it.
> >
> >
On Thu, Jun 21, 2012 at 23:58:10 +0400, Andrey V. Elsukov wrote:
> On 21.06.2012 20:48, Kenneth D. Merry wrote:
> >>> In this case, the GEOM disk class instance has been created by
> >>> disk_create(), and the taste of the disk is queued in the GEOM
> >>>
On Fri, Jun 22, 2012 at 19:50:01 +0300, Alexander Motin wrote:
> Hi.
>
> I understand problem you are going to fix and I think your patch should
> do it. What I don't very like is addition of new GEOM method. Now GEOM
> doesn't need it because all internal open/close operations and provider
> d
On Tue, Jun 26, 2012 at 19:41:07 -0400, Benjamin Kaduk wrote:
> On Tue, 26 Jun 2012, Michael Butler wrote:
>
> >As follows, in "g_disk_providergone", a NULL pointer reference?:
>
> g_disk_providergone() is new in r237518 (by ken); ken cc'd.
Can you try the attached patch to sys/geom/geom_disk.c?
On Wed, Jun 27, 2012 at 10:22:59 -0400, Michael Butler wrote:
> On 06/26/12 22:29, Kenneth D. Merry wrote:
> > On Tue, Jun 26, 2012 at 19:41:07 -0400, Benjamin Kaduk wrote:
> >> On Tue, 26 Jun 2012, Michael Butler wrote:
> >>
> >>> As follows, in "g_
On Sat, Aug 31, 2013 at 13:07:53 -0400, Sam Fourman Jr. wrote:
> Hello list
>
> I have two issues that may in fact be both related to the LSI SAS2008 card
> or
> the mps(4) driver.
>
> this server is running FreeBSD 10.0-CURRENT #0 r255089
>
>
> 1) All of the SSD disks are showing up at SATA2 3
On Thu, Apr 07, 2011 at 13:59:35 +0300, Alexander Motin wrote:
> Alexander Best wrote:
> > On Fri Apr 1 11, John Baldwin wrote:
> >> On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote:
> >>> i think there are multiple issues with devstat. i found the following in
> >>> devicestat.h:
>
>
On Sun, Apr 10, 2011 at 23:19:31 +0300, Alexander Motin wrote:
> Alexander Best wrote:
> > On Thu Apr 7 11, Alexander Motin wrote:
> >> Alexander Best wrote:
> >>> On Fri Apr 1 11, John Baldwin wrote:
> On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote:
> > i think there are mu
On Mon, Apr 11, 2011 at 19:09:00 +0300, Alexander Motin wrote:
> On 11.04.2011 18:43, Kenneth D. Merry wrote:
> >On Sun, Apr 10, 2011 at 23:19:31 +0300, Alexander Motin wrote:
> >>Alexander Best wrote:
> >>>2) the pass* devices still don't show up under i
Hey folks,
I have attached some patches to the kernel message buffer code (this
affects dmesg(8) output as well as kernel messages that go to the syslog)
to address log scrambling.
This fixes the same issue that 'options PRINTF_BUFR_SIZE=128' fixes for the
console.
The problem is that you can ha
On Sat, May 28, 2011 at 11:26:50 -0700, Julian Elischer wrote:
> On 5/27/11 3:45 PM, Kenneth D. Merry wrote:
> >Hey folks,
> >
> >I have attached some patches to the kernel message buffer code (this
> >affects dmesg(8) output as well as kernel messages that go to th
On Mon, Jun 20, 2011 at 15:46:56 +0400, Andrey Chernov wrote:
> On Mon, Jun 20, 2011 at 11:01:46AM +0300, Kostik Belousov wrote:
> > On Mon, Jun 20, 2011 at 11:02:22AM +0400, Andrey Chernov wrote:
> > > On Sun, Jun 19, 2011 at 08:15:43PM -0600, Justin T. Gibbs wrote:
> > > > On 6/19/11 6:19 PM, And
On Wed, Jun 22, 2011 at 00:49:34 +0400, Andrey Chernov wrote:
> On Tue, Jun 21, 2011 at 10:17:19AM -0600, Kenneth D. Merry wrote:
> > ps
> > alltrace
> > show locks
> > show msgbuf
> >
> > Hopefully that will give us something to start looking at...
> >
On Wed, Jun 22, 2011 at 08:13:25 +0400, Andrey Chernov wrote:
> On Tue, Jun 21, 2011 at 09:54:04PM -0600, Kenneth D. Merry wrote:
> > These two are interesting:
> >
> > > http://img825.imageshack.us/img825/1249/21062011014m.jpg
> > > http://img839.imagesha
301 - 342 of 342 matches
Mail list logo
