search for: serdes

Author: motu Repository: /hg/zfs-crypto/gate Revision: cf616258f6c9e546db6d1ed74f00e434f369e5e7 Log message: 6222529 obsolete serd properties are not reported as illegal Files: update: usr/src/cmd/fm/eversholt/common/check.c

I have a machine with a running samba 3.0.24 with winbind. After an update to 3.0.25c I couldn't connect from win clients. So I first tried to rejoin and got some errors about trust account problems - sorry didn't save them. Then I deletet the account the tried a fresh join from the machine: net rpc join -Uaga -Waag -Serde Password: [2007/08/23 11:13:39, 0]

Paul, On Thu, Mar 17, 2016 at 5:47 PM, Digimer <lists at alteeve.ca> wrote: > On 17/03/16 04:47 PM, paul.greene.va at verizon.net wrote: > > Thanks, I followed the 2nd article, and it got the existing virtual > > machines communicating with each other. > Right, so your VMs are on the same bridge group now (at Layer2 of OSI). > > > > However, any new

On Fri, 2016-03-18 at 13:02 -0400, Mike - st257 wrote: > Paul, > > > On Thu, Mar 17, 2016 at 5:47 PM, Digimer <lists at alteeve.ca> wrote: > On 17/03/16 04:47 PM, paul.greene.va at verizon.net wrote: > > Thanks, I followed the 2nd article, and it got the existing > virtual > > machines communicating with each other. > >

running b37 on amd64. after removing power from a disk configured as a mirror, 10 minutes has passed and ZFS has still not offlined it. # zpool status tank pool: tank state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear

Tonight I''ve been moving some of my personal data around on my desktop system and have hit some on-disk corruption. As you may know, I''m cursed, and so this had a high probability of ending badly. I have two SCSI disks and use live upgrade, and I have a partition, /aux0, where I tend to keep personal stuff. This is on an SB2500 running snv_46. The upshot is that I have a slice

Hi all, yesterday we had a drive failure on a fc-al jbod with 14 drives. Suddenly the zpool using that jbod stopped to respond to I/O requests and we get tons of the following messages on /var/adm/messages: Sep 3 15:20:10 fb2 scsi: [ID 107833 kern.warning] WARNING: /scsi_vhci/disk at g20000004cfd81b9f (sd52): Sep 3 15:20:10 fb2 SCSI transport failed: reason ''timeout'':

...r - version 5.6.10.1-k2 Copyright (c) 1999-2004 Intel Corporation. pcnet32.c:v1.30i 06.28.2004 tsbogend@alpha.franken.de e100: Intel(R) PRO/100 Network Driver, 3.3.6-k2-NAPI e100: Copyright(c) 1999-2004 Intel Corporation tg3.c:v3.23 (February 15, 2005) eth0: Tigon3 [partno(BCM95704A41) rev 2100 PHY(serdes)] (PCIX:133MHz:64- bit) 10/100/1000BaseT Ethernet 00:11:25:9d:63:18 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOcap[0] eth1: Tigon3 [partno(BCM95704A41) rev 2100 PHY(serdes)] (PCIX:133MHz:64- bit) 10/100/1000BaseT Ethernet 00:11:25:9d:63:19 eth1: RXcsums[1] LinkChgREG[0]...

...argv4.package.elements = obj_args; > > obj = acpi_evaluate_dsm(ACPI_HANDLE(mac_cb->dsaf_dev->dev), > - hns_dsaf_acpi_dsm_uuid, 0, > + &hns_dsaf_acpi_dsm_uuid, 0, > HNS_OP_SERDES_LP_FUNC, &argv4); > if (!obj) { > dev_warn(mac_cb->dsaf_dev->dev, "set port%d serdes lp fail!", > diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c > index 001860361434..eb612123e0dd 100644 > --- a/drivers/pci/pci-acpi.c > +++...

...!= ACPI_TYPE_INTEGER) @@ -565,7 +564,7 @@ hns_mac_config_sds_loopback_acpi(struct hns_mac_cb *mac_cb, bool en) argv4.package.elements = obj_args; obj = acpi_evaluate_dsm(ACPI_HANDLE(mac_cb->dsaf_dev->dev), - hns_dsaf_acpi_dsm_uuid, 0, + &hns_dsaf_acpi_dsm_uuid, 0, HNS_OP_SERDES_LP_FUNC, &argv4); if (!obj) { dev_warn(mac_cb->dsaf_dev->dev, "set port%d serdes lp fail!", diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c index 001860361434..eb612123e0dd 100644 --- a/drivers/pci/pci-acpi.c +++ b/drivers/pci/pci-acpi.c @@ -24,10 +24,9 @@ *...

As mentioned last night, we''ve been reviewing a proposal for hot spare support in ZFS. Below you can find a current draft of the proposed interfaces. This has not yet been submitted for ARC review, but comments are welcome. Note that this does not include any enhanced FMA diagnosis to determine when a device is "faulted". This will come in a follow-on project, of which some