Re: 8.3: kernel panic in bpf.c catchpacket()

2012-10-17 Thread Guy Helmer 
On Oct 12, 2012, at 8:54 AM, Guy Helmer  wrote:

> 
> On Oct 10, 2012, at 1:37 PM, Alexander V. Chernikov  
> wrote:
> 
>> On 10.10.2012 00:36, Guy Helmer wrote:
>>> 
>>> On Oct 8, 2012, at 8:09 AM, Guy Helmer  wrote:
>>> 
 I'm seeing a consistent new kernel panic in FreeBSD 8.3:
 I'm not seeing how bd_sbuf would be NULL here. Any ideas?
>>> 
>>> Since I've not had any replies, I hope nobody minds if I reply with more 
>>> information.
>>> 
>>> This panic seems to be occasionally triggered now that my user land code is 
>>> changing the packet filter a while after the bpd device has been opened and 
>>> an initial packet filter was set (previously, my code did not change the 
>>> filter after it was initially set).
>>> 
>>> I'm focusing on bpf_setf() since that seems to be the place that could be 
>>> tickling a problem, and I see that bpf_setf() calls reset_d(d) to clear the 
>>> hold buffer. I have manually verified that the BPFD lock is held during the 
>>> call to reset_d(), and the lock is held every other place that the buffers 
>>> are manipulated, so I haven't been able to find any place that seems 
>>> vulnerable to losing one of the bpf buffers. Still searching, but any help 
>>> would be appreciated.
>> 
>> Can you please check this code on -current?
>> Locking has changed quite significantly some time ago, so there is good 
>> chance that you can get rid of this panic (or discover different one which 
>> is really "new") :).
> 
> I'm not ready to run this app on current, so I have merged revs 229898, 
> 233937, 233938, 233946, 235744, 235745, 235746, 235747, 236231, 236251, 
> 236261, 236262, 236559, and 236806 to my 8.3 checkout to get code that should 
> be virtually identical to current without the timestamp changes.
> 
> Unfortunately, I have only been able to trigger the panic in my test lab once 
> -- so I'm not sure whether a lack of problems with the updated code will be 
> indicative of likely success in the field where this has been trigged 
> regularly at some sites…
> 
> Thanks,
> Guy
> 


FWIW, I was able to trigger the panic with the original 8.3 code again in my 
test lab. With these changes resulting from merging the revs mentioned above, I 
have not seen any panics in my test lab setup in two days of load testing, and 
AFAIK, packet capturing seems to be working fine.

I've included the diffs for reference for anyone encountering the issue.

Thanks, Alexander!

Guy

Index: net/bpf.c
===
--- net/bpf.c   (revision 239830)
+++ net/bpf.c   (working copy)
@@ -43,6 +43,8 @@
 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -66,6 +68,7 @@
 #include 
 
 #include 
+#defineBPF_INTERNAL
 #include 
 #include 
 #ifdef BPF_JITTER
@@ -139,6 +142,7 @@
 
 static voidbpf_attachd(struct bpf_d *, struct bpf_if *);
 static voidbpf_detachd(struct bpf_d *);
+static voidbpf_detachd_locked(struct bpf_d *);
 static voidbpf_freed(struct bpf_d *);
 static int bpf_movein(struct uio *, int, struct ifnet *, struct mbuf **,
struct sockaddr *, int *, struct bpf_insn *);
@@ -150,7 +154,7 @@
void (*)(struct bpf_d *, caddr_t, u_int, void *, u_int),
struct timeval *);
 static voidreset_d(struct bpf_d *);
-static int  bpf_setf(struct bpf_d *, struct bpf_program *, u_long cmd);
+static int bpf_setf(struct bpf_d *, struct bpf_program *, u_long cmd);
 static int bpf_getdltlist(struct bpf_d *, struct bpf_dltlist *);
 static int bpf_setdlt(struct bpf_d *, u_int);
 static voidfilt_bpfdetach(struct knote *);
@@ -168,6 +172,12 @@
 SYSCTL_NODE(_net_bpf, OID_AUTO, stats, CTLFLAG_MPSAFE | CTLFLAG_RW,
 bpf_stats_sysctl, "bpf statistics portal");
 
+static VNET_DEFINE(int, bpf_optimize_writers) = 0;
+#defineV_bpf_optimize_writers VNET(bpf_optimize_writers)
+SYSCTL_VNET_INT(_net_bpf, OID_AUTO, optimize_writers,
+CTLFLAG_RW, &VNET_NAME(bpf_optimize_writers), 0,
+"Do not send packets until BPF program is set");
+
 static d_open_tbpfopen;
 static d_read_tbpfread;
 static d_write_t   bpfwrite;
@@ -189,7 +199,38 @@
 static struct filterops bpfread_filtops =
{ 1, NULL, filt_bpfdetach, filt_bpfread };
 
+eventhandler_tag   bpf_ifdetach_cookie = NULL;
+
 /*
+ * LOCKING MODEL USED BY BPF:
+ * Locks:
+ * 1) global lock (BPF_LOCK). Mutex, used to protect interface 
addition/removal,
+ * some global counters and every bpf_if reference.
+ * 2) Interface lock. Rwlock, used to protect list of BPF descriptors and 
their filters.
+ * 3) Descriptor lock. Mutex, used to protect BPF buffers and various 
structure fields
+ *   used by bpf_mtap code.
+ *
+ * Lock order:
+ *
+ * Global lock, interface lock, descriptor lock
+ *
+ * We have to acquire interface lock before descriptor main lock due to 
BPF_MTAP[2]
+ * working model. In many places (like bpf_detachd) we start with BPF 
descri

9.1-RC2 ixgbe lagg problems

2012-10-17 Thread Wynn Wilkes 
I'm testing out a networking configuration that creates a lagg1
interface that uses lacp with the ix0 and ix1 interfaces. The lagg1
interface I've set up always just reports:
laggport: ix1 flags=18
laggport: ix0 flags=18

Missing the ACTIVE flag that working lagg interfaces report.

The built in ixgbe driver is at version 2.4.8 in the 9.1-RC2 release I
upgraded to. The problem is very similar to this blog post:
http://christopher-technicalmusings.blogspot.com/2012/03/freebsd-90-and-intel-x520s-ixgbe-2311.html

and this mailing list thread:
http://comments.gmane.org/gmane.os.freebsd.stable/79650

I've tried the 2.4.4 driver from Intel's site, but it still has the
same problems. Is a lagg using lacp with the ix interfaces working for
anyone else?

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

Re: mpt irq timeout problem after reboot - only if non-verbose booting !?!

2012-10-17 Thread John Baldwin 
On Tuesday, October 16, 2012 5:24:44 am Harald Schmalzbauer wrote:
>  Hello,
> 
> I have 9.1-RC2 running in an ESXi 5.1 guest.
> I use 'lsisas' as virtual SCSI-Controller and mpt attaches and finds 1068E.
> 
> Everything is working fine until the first 'shutdown -r now':
> The second boot pauses for ~2 minutes after probing disks and continues
> with this error:
> mpt0: Timedout requests already complete. Interrupts may not be functioning.

To be clear, you only see this at the end of reboot, and the hardware is fine
once the machine is back up?

> This problem was also obeserved with real 1068 hardware:
> http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063937.html
> 
> When I power off the virtual machine instead of rebooting, the problem
> doesn't occur.
> 
> Accidentally I found a workarround ;-) :
> If I set 'verbose_boot' in loader.conf, the problem vanisehs!?!?!?
> 
> Any idea how „verbose_boot“ affects the operation of the mpt driver?

Extra printfs affect the timing most likely.

Are you using any RAID volumes?  The only shutdown handler in mpt that looks
like it might want interrupts to work is mpt_raid_shutdown().  It needs to use
polled I/O instead of disabling interrupts I think.  Try this:

Index: mpt_raid.c
===
--- mpt_raid.c  (revision 241641)
+++ mpt_raid.c  (working copy)
@@ -115,7 +115,7 @@ static timeout_t mpt_raid_timer;
 static void mpt_enable_vol(struct mpt_softc *mpt,
   struct mpt_raid_volume *mpt_vol, int enable);
 #endif
-static void mpt_verify_mwce(struct mpt_softc *, struct mpt_raid_volume *);
+static void mpt_verify_mwce(struct mpt_softc *, struct mpt_raid_volume *, int);
 static void mpt_adjust_queue_depth(struct mpt_softc *, struct mpt_raid_volume 
*,
 struct cam_path *);
 #if __FreeBSD_version < 50
@@ -135,7 +135,7 @@ static void mpt_disk_prt(struct mpt_softc *mpt, st
 static int mpt_issue_raid_req(struct mpt_softc *mpt,
 struct mpt_raid_volume *vol, struct mpt_raid_disk *disk, request_t *req,
 u_int Action, uint32_t ActionDataWord, bus_addr_t addr, bus_size_t len,
-int write, int wait);
+int write, int wait, int sleep_ok);
 
 static int mpt_refresh_raid_data(struct mpt_softc *mpt);
 static void mpt_schedule_raid_refresh(struct mpt_softc *mpt);
@@ -517,7 +517,7 @@ mpt_raid_shutdown(struct mpt_softc *mpt)
 
mpt->raid_mwce_setting = MPT_RAID_MWCE_OFF;
RAID_VOL_FOREACH(mpt, mpt_vol) {
-   mpt_verify_mwce(mpt, mpt_vol);
+   mpt_verify_mwce(mpt, mpt_vol, FALSE);
}
 }
 
@@ -592,7 +592,7 @@ static int
 mpt_issue_raid_req(struct mpt_softc *mpt, struct mpt_raid_volume *vol,
   struct mpt_raid_disk *disk, request_t *req, u_int Action,
   uint32_t ActionDataWord, bus_addr_t addr, bus_size_t len,
-  int write, int wait)
+  int write, int wait, int sleep_ok)
 {
MSG_RAID_ACTION_REQUEST *rap;
SGE_SIMPLE32 *se;
@@ -623,7 +623,7 @@ mpt_issue_raid_req(struct mpt_softc *mpt, struct m
 
if (wait) {
return (mpt_wait_req(mpt, req, REQ_STATE_DONE, REQ_STATE_DONE,
-/*sleep_ok*/FALSE, /*time_ms*/2000));
+sleep_ok, /*time_ms*/2000));
} else {
return (0);
}
@@ -763,7 +763,7 @@ mpt_raid_quiesce_disk(struct mpt_softc *mpt, struc
MPI_RAID_ACTION_QUIESCE_PHYS_IO,
/*ActionData*/0, /*addr*/0,
/*len*/0, /*write*/FALSE,
-   /*wait*/FALSE);
+   /*wait*/FALSE, /*sleep_ok*/FALSE);
if (rv != 0)
return (CAM_REQ_CMP_ERR);
 
@@ -882,7 +882,7 @@ mpt_enable_vol(struct mpt_softc *mpt, struct mpt_r
enable ? MPI_RAID_ACTION_ENABLE_VOLUME
   : MPI_RAID_ACTION_DISABLE_VOLUME,
/*data*/0, /*addr*/0, /*len*/0,
-   /*write*/FALSE, /*wait*/TRUE);
+   /*write*/FALSE, /*wait*/TRUE, /*sleep_ok*/TRUE);
if (rv == ETIMEDOUT) {
mpt_vol_prt(mpt, mpt_vol, "mpt_enable_vol: "
"%s Volume Timed-out\n",
@@ -903,7 +903,8 @@ mpt_enable_vol(struct mpt_softc *mpt, struct mpt_r
 #endif
 
 static void
-mpt_verify_mwce(struct mpt_softc *mpt, struct mpt_raid_volume *mpt_vol)
+mpt_verify_mwce(struct mpt_softc *mpt, struct mpt_raid_volume *mpt_vol,
+int sleep_ok)
 {
request_t *req;
struct mpt_raid_action_result *ar;
@@ -950,7 +951,7 @@ static void
return;
}
 
-   req = mpt_get_request(mpt, /*sleep_ok*/TRUE);
+   req = mpt_get_request(mpt, sleep_ok);
if (req == NULL) {

Re: 9.1-RC2 ixgbe lagg problems

2012-10-17 Thread Garrett Wollman 
In article
,
wynnwil...@gmail.com writes:

>I've tried the 2.4.4 driver from Intel's site, but it still has the
>same problems. Is a lagg using lacp with the ix interfaces working for
>anyone else?

You bet.

lagg0: flags=8943
metric 0 mtu 9120

options=401bb
ether 04:7d:7b:a5:88:f0
inet 128.30.3.34 netmask 0xff00 broadcast 128.30.3.255
nd6 options=29
media: Ethernet autoselect
status: active
laggproto lacp lagghash l2,l3,l4
laggport: ix1 flags=1c
laggport: ix0 flags=1c

Configured with:

cloned_interfaces="lagg0"
ifconfig_ix0="mtu 9120 up"
ifconfig_ix1="mtu 9120 up"
ifconfig_lagg0="laggproto lacp laggport ix0 laggport ix1"
ipv4_addrs_lagg0="128.30.x.x/24"

-GAWollman

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

Re: mpt irq timeout problem after reboot - only if non-verbose booting !?!

2012-10-17 Thread Harald Schmalzbauer (mobil) 

-Ursprüngliche Nachricht-

Von: John Baldwin 
An: freebsd-stable@freebsd.org
Cc: h.schmalzba...@omnilan.de
Gesendet: 17.10.'12,  20:46

On Tuesday, October 16, 2012 5:24:44 am Harald Schmalzbauer wrote:

 Hello,

I have 9.1-RC2 running in an ESXi 5.1 guest.
I use 'lsisas' as virtual SCSI-Controller and mpt attaches and finds 1068E.

Everything is working fine until the first 'shutdown -r now':
The second boot pauses for ~2 minutes after probing disks and continues
with this error:
mpt0: Timedout requests already complete. Interrupts may not be functioning.


To be clear, you only see this at the end of reboot, and the hardware is fine
once the machine is back up?

.

Thanks for your attention!
The timeout occurs after the first 'shutdown -r' while device probing during 
second boot process.
Perhaps this is amd64 specific. Today I had a new i386 setup which doesn't 
exhibit this timeout. But it's on different hardware and hv-host was 5.0 
inestead 5.1. So not really representative...


Extra printfs affect the timing most likely.

Are you using any RAID volumes?  The only shutdown handler in mpt that looks


The controller is 'virtual' SAS. But thers's been reports that also on real HW 
(sasuc8i) the same problem occurs.

I'll try your patch tomorrow morning; timezon shift...

Thanks,

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

Problem reading vitals from Gigabyte H77-DH3H

2012-10-17 Thread Derek Kulinski 
Hello everyone,

I'm unable to read temperature Gigabyte H77-DH3H motherboard. Is that
motherboard supported or am I doing it incorrectly?

When trying to access hw.acpi.thermal everything appears to be ok, but
it is not, the system always returns 27,8C and 29,8C which fooled me
initially - the values never change.

Here is output:
[chinatsu]:/root# sysctl hw.acpi.thermal
hw.acpi.thermal.min_runtime: 0
hw.acpi.thermal.polling_rate: 10
hw.acpi.thermal.user_override: 0
hw.acpi.thermal.tz0.temperature: 27,8C
hw.acpi.thermal.tz0.active: 2
hw.acpi.thermal.tz0.passive_cooling: 0
hw.acpi.thermal.tz0.thermal_flags: 0
hw.acpi.thermal.tz0._PSV: -1
hw.acpi.thermal.tz0._HOT: -1
hw.acpi.thermal.tz0._CRT: 106,0C
hw.acpi.thermal.tz0._ACx: 85,0C 55,0C 0,0C 0,0C 0,0C -1 -1 -1 -1 -1
hw.acpi.thermal.tz0._TC1: -1
hw.acpi.thermal.tz0._TC2: -1
hw.acpi.thermal.tz0._TSP: -1
hw.acpi.thermal.tz1.temperature: 29,8C
hw.acpi.thermal.tz1.active: -1
hw.acpi.thermal.tz1.passive_cooling: 1
hw.acpi.thermal.tz1.thermal_flags: 0
hw.acpi.thermal.tz1._PSV: 106,0C
hw.acpi.thermal.tz1._HOT: -1
hw.acpi.thermal.tz1._CRT: 106,0C
hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
hw.acpi.thermal.tz1._TC1: 1
hw.acpi.thermal.tz1._TC2: 5
hw.acpi.thermal.tz1._TSP: 10

Since above method fails, I decided to try motherboard monitors in
ports. It seems that almost all of them rely on /dev/smb device.

After loading smb and ichsmb (seems like ichsmb is the only driver
that causes /dev/smb0) any access to /dev/smb0 returns "Device
not configured". For example:

[chinatsu]:/root# lmmon
IOCTL: Device not configured

Similarly mbmon fails:
[chinatsu]:/root# mbmon -V
No VIA686 HWM available!!
InitMBInfo: No error: 0
Exit 1
[chinatsu]:/root# mbmon -S
No SMBus HWM available!!
InitMBInfo: No error: 0
Exit 1
[chinatsu]:/root# mbmon -I
No ISA-IO HWM available!!
InitMBInfo: No error: 0
Exit 1
[chinatsu]:/root# mbmon -A
InitMBInfo: No error: 0
This program needs "setuid root"!!
Exit 1

Here's output of pciconf:

[chinatsu]:/root# pciconf -lv
hostb0@pci0:0:0:0:  class=0x06 card=0x50001458 chip=0x01508086 rev=0x09 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Ivy Bridge DRAM Controller'
class  = bridge
subclass   = HOST-PCI
vgapci0@pci0:0:2:0: class=0x03 card=0xd0001458 chip=0x01528086 rev=0x09 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Ivy Bridge Graphics Controller'
class  = display
subclass   = VGA
xhci0@pci0:0:20:0:  class=0x0c0330 card=0x50071458 chip=0x1e318086 rev=0x04 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Panther Point USB xHCI Host Controller'
class  = serial bus
subclass   = USB
none0@pci0:0:22:0:  class=0x078000 card=0x1c3a1458 chip=0x1e3a8086 rev=0x04 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Panther Point MEI Controller'
class  = simple comms
ehci0@pci0:0:26:0:  class=0x0c0320 card=0x50061458 chip=0x1e2d8086 rev=0x04 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Panther Point USB Enhanced Host Controller'
class  = serial bus
subclass   = USB
pcib1@pci0:0:28:0:  class=0x060400 card=0x50011458 chip=0x1e108086 rev=0xc4 
hdr=0x01
vendor = 'Intel Corporation'
device = 'Panther Point PCI Express Root Port 1'
class  = bridge
subclass   = PCI-PCI
pcib2@pci0:0:28:2:  class=0x060400 card=0x50011458 chip=0x1e148086 rev=0xc4 
hdr=0x01
vendor = 'Intel Corporation'
device = 'Panther Point PCI Express Root Port 3'
class  = bridge
subclass   = PCI-PCI
pcib3@pci0:0:28:3:  class=0x060401 card=0x50011458 chip=0x244e8086 rev=0xc4 
hdr=0x01
vendor = 'Intel Corporation'
device = '82801 PCI Bridge'
class  = bridge
subclass   = PCI-PCI
ehci1@pci0:0:29:0:  class=0x0c0320 card=0x50061458 chip=0x1e268086 rev=0x04 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Panther Point USB Enhanced Host Controller'
class  = serial bus
subclass   = USB
isab0@pci0:0:31:0:  class=0x060100 card=0x50011458 chip=0x1e4a8086 rev=0x04 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Panther Point LPC Controller'
class  = bridge
subclass   = PCI-ISA
ahci0@pci0:0:31:2:  class=0x010601 card=0xb0051458 chip=0x1e028086 rev=0x04 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Panther Point 6 port SATA AHCI Controller'
class  = mass storage
subclass   = SATA
ichsmb0@pci0:0:31:3:class=0x0c0500 card=0x50011458 chip=0x1e228086 rev=0x04 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Panther Point SMBus Controller'
class  = serial bus
subclass   = SMBus
alc0@pci0:2:0:0:class=0x02 card=0xe0001458 chip=0x10831969 rev=0xc0 
hdr=0x00
vendor = 'Atheros Communications'
device = 'AR8151 v2.0 Gigabit Ethernet'
class  = network
subclass   = ethernet
pcib4@pci0:3:0:0:

Re: Problem reading vitals from Gigabyte H77-DH3H

2012-10-17 Thread Andriy Gapon 
on 17/10/2012 23:15 Derek Kulinski said the following:
> Hello everyone,
> 
> I'm unable to read temperature Gigabyte H77-DH3H motherboard. Is that
> motherboard supported or am I doing it incorrectly?
> 
> When trying to access hw.acpi.thermal everything appears to be ok, but
> it is not, the system always returns 27,8C and 29,8C which fooled me
> initially - the values never change.

I've found that on quite a few modern systems the ACPI platform advertises some
useless thermal zones, which always return some hardcoded temperatures.
E.g. I have Asus P8Z77-M PRO near me and it also reports two thermal zones.
Looking at DSDT (acpidump -dt) I see that the temperatures are hardcoded.

It seems that your motherboard has an ITE Super I/O with hardware monitoring
function.  I am not sure which model though...
Your best bet would be it(4) driver, but it is not committed yet.
If you are into some mild hacking (applying patches, building custom kernel),
then I can point you to the patches.
Although I can not give a firm guarantee that the driver supports your HWM chip,
since I don't know the model.


> Here is output:
> [chinatsu]:/root# sysctl hw.acpi.thermal
> hw.acpi.thermal.min_runtime: 0
> hw.acpi.thermal.polling_rate: 10
> hw.acpi.thermal.user_override: 0
> hw.acpi.thermal.tz0.temperature: 27,8C
> hw.acpi.thermal.tz0.active: 2
> hw.acpi.thermal.tz0.passive_cooling: 0
> hw.acpi.thermal.tz0.thermal_flags: 0
> hw.acpi.thermal.tz0._PSV: -1
> hw.acpi.thermal.tz0._HOT: -1
> hw.acpi.thermal.tz0._CRT: 106,0C
> hw.acpi.thermal.tz0._ACx: 85,0C 55,0C 0,0C 0,0C 0,0C -1 -1 -1 -1 -1
> hw.acpi.thermal.tz0._TC1: -1
> hw.acpi.thermal.tz0._TC2: -1
> hw.acpi.thermal.tz0._TSP: -1
> hw.acpi.thermal.tz1.temperature: 29,8C
> hw.acpi.thermal.tz1.active: -1
> hw.acpi.thermal.tz1.passive_cooling: 1
> hw.acpi.thermal.tz1.thermal_flags: 0
> hw.acpi.thermal.tz1._PSV: 106,0C
> hw.acpi.thermal.tz1._HOT: -1
> hw.acpi.thermal.tz1._CRT: 106,0C
> hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
> hw.acpi.thermal.tz1._TC1: 1
> hw.acpi.thermal.tz1._TC2: 5
> hw.acpi.thermal.tz1._TSP: 10
> 
> Since above method fails, I decided to try motherboard monitors in
> ports. It seems that almost all of them rely on /dev/smb device.
> 
> After loading smb and ichsmb (seems like ichsmb is the only driver
> that causes /dev/smb0) any access to /dev/smb0 returns "Device
> not configured". For example:
> 
> [chinatsu]:/root# lmmon
> IOCTL: Device not configured
> 
> Similarly mbmon fails:
> [chinatsu]:/root# mbmon -V
> No VIA686 HWM available!!
> InitMBInfo: No error: 0
> Exit 1
> [chinatsu]:/root# mbmon -S
> No SMBus HWM available!!
> InitMBInfo: No error: 0
> Exit 1
> [chinatsu]:/root# mbmon -I
> No ISA-IO HWM available!!
> InitMBInfo: No error: 0
> Exit 1
> [chinatsu]:/root# mbmon -A
> InitMBInfo: No error: 0
> This program needs "setuid root"!!
> Exit 1
> 
> Here's output of pciconf:

These tools from ports are very outdated and thus do not support new hardware.

> [chinatsu]:/root# pciconf -lv
> hostb0@pci0:0:0:0:  class=0x06 card=0x50001458 chip=0x01508086 
> rev=0x09 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Ivy Bridge DRAM Controller'
> class  = bridge
> subclass   = HOST-PCI
> vgapci0@pci0:0:2:0: class=0x03 card=0xd0001458 chip=0x01528086 
> rev=0x09 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Ivy Bridge Graphics Controller'
> class  = display
> subclass   = VGA
> xhci0@pci0:0:20:0:  class=0x0c0330 card=0x50071458 chip=0x1e318086 
> rev=0x04 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Panther Point USB xHCI Host Controller'
> class  = serial bus
> subclass   = USB
> none0@pci0:0:22:0:  class=0x078000 card=0x1c3a1458 chip=0x1e3a8086 
> rev=0x04 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Panther Point MEI Controller'
> class  = simple comms
> ehci0@pci0:0:26:0:  class=0x0c0320 card=0x50061458 chip=0x1e2d8086 
> rev=0x04 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Panther Point USB Enhanced Host Controller'
> class  = serial bus
> subclass   = USB
> pcib1@pci0:0:28:0:  class=0x060400 card=0x50011458 chip=0x1e108086 
> rev=0xc4 hdr=0x01
> vendor = 'Intel Corporation'
> device = 'Panther Point PCI Express Root Port 1'
> class  = bridge
> subclass   = PCI-PCI
> pcib2@pci0:0:28:2:  class=0x060400 card=0x50011458 chip=0x1e148086 
> rev=0xc4 hdr=0x01
> vendor = 'Intel Corporation'
> device = 'Panther Point PCI Express Root Port 3'
> class  = bridge
> subclass   = PCI-PCI
> pcib3@pci0:0:28:3:  class=0x060401 card=0x50011458 chip=0x244e8086 
> rev=0xc4 hdr=0x01
> vendor = 'Intel Corporation'
> device = '82801 PCI Bridge'
> class  = bridge
> subclass   = PCI-PCI
> ehci1@pci0:0:29:0:  class=0x0c0320 card=0x50061458 chip=0x1e268086 
> rev=0x04 hdr=0x00
>

Re: Problem reading vitals from Gigabyte H77-DH3H

2012-10-17 Thread Derek Kulinski 
On Wed, Oct 17, 2012 at 11:38:57PM +0300, Andriy Gapon wrote:
> I've found that on quite a few modern systems the ACPI platform advertises 
> some
> useless thermal zones, which always return some hardcoded temperatures.
> E.g. I have Asus P8Z77-M PRO near me and it also reports two thermal zones.
> Looking at DSDT (acpidump -dt) I see that the temperatures are hardcoded.
> 
> It seems that your motherboard has an ITE Super I/O with hardware monitoring
> function.  I am not sure which model though...
> Your best bet would be it(4) driver, but it is not committed yet.
> If you are into some mild hacking (applying patches, building custom kernel),
> then I can point you to the patches.
> Although I can not give a firm guarantee that the driver supports your HWM 
> chip,
> since I don't know the model.

I'm open to experimenting. It's kind of important to me, because I recently had 
heating issue (that I hopefully fixed) and I wasn't aware of problems until my 
system started freezing. I was fooled by those values thinking everything was 
ok.

> [...]
>
> These tools from ports are very outdated and thus do not support new hardware.

I never used them before since on my old box hw.acpi.thermal worked fine.
Is there anything in ports that you would recommend?

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

9.1-RC2 - could it be that the installer does not write the MBR?

2012-10-17 Thread Rainer Duffner 
Hi,

I tried to install 9.1-RC2 amd64 on two disks that previously had some version 
of Solaris installed (with grub as boot-manager).
The installation would always be successful, but it would just boot to grub and 
then sit there.

It's a rather old G1 BL460C blade, but 9.0 installs flawlessly.

I didn't have time to really test it through because the server needed to get 
installed and it had taken me some time to realize what had happened.

Maybe someone might want to look into this.


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

Re: 9.1-RC2 - could it be that the installer does not write the MBR?

2012-10-17 Thread Brandon Allbery 
On Wed, Oct 17, 2012 at 4:56 PM, Rainer Duffner wrote:

> I tried to install 9.1-RC2 amd64 on two disks that previously had some
> version of Solaris installed (with grub as boot-manager).
> The installation would always be successful, but it would just boot to
> grub and then sit there.
>

RC1 wasn't very good at it either.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix/linux, openafs, kerberos, infrastructure  http://sinenomine.net
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.3: kernel panic in bpf.c catchpacket()

2012-10-17 Thread Guy Helmer 
On Oct 17, 2012, at 8:58 AM, Guy Helmer  wrote:

> On Oct 12, 2012, at 8:54 AM, Guy Helmer  wrote:
> 
>> 
>> On Oct 10, 2012, at 1:37 PM, Alexander V. Chernikov  
>> wrote:
>> 
>>> On 10.10.2012 00:36, Guy Helmer wrote:
 
 On Oct 8, 2012, at 8:09 AM, Guy Helmer  wrote:
 
> I'm seeing a consistent new kernel panic in FreeBSD 8.3:
> I'm not seeing how bd_sbuf would be NULL here. Any ideas?
 
 Since I've not had any replies, I hope nobody minds if I reply with more 
 information.
 
 This panic seems to be occasionally triggered now that my user land code 
 is changing the packet filter a while after the bpd device has been opened 
 and an initial packet filter was set (previously, my code did not change 
 the filter after it was initially set).
 
 I'm focusing on bpf_setf() since that seems to be the place that could be 
 tickling a problem, and I see that bpf_setf() calls reset_d(d) to clear 
 the hold buffer. I have manually verified that the BPFD lock is held 
 during the call to reset_d(), and the lock is held every other place that 
 the buffers are manipulated, so I haven't been able to find any place that 
 seems vulnerable to losing one of the bpf buffers. Still searching, but 
 any help would be appreciated.
>>> 
>>> Can you please check this code on -current?
>>> Locking has changed quite significantly some time ago, so there is good 
>>> chance that you can get rid of this panic (or discover different one which 
>>> is really "new") :).
>> 
>> I'm not ready to run this app on current, so I have merged revs 229898, 
>> 233937, 233938, 233946, 235744, 235745, 235746, 235747, 236231, 236251, 
>> 236261, 236262, 236559, and 236806 to my 8.3 checkout to get code that 
>> should be virtually identical to current without the timestamp changes.
>> 
>> Unfortunately, I have only been able to trigger the panic in my test lab 
>> once -- so I'm not sure whether a lack of problems with the updated code 
>> will be indicative of likely success in the field where this has been 
>> trigged regularly at some sites…
>> 
>> Thanks,
>> Guy
>> 
> 
> 
> FWIW, I was able to trigger the panic with the original 8.3 code again in my 
> test lab. With these changes resulting from merging the revs mentioned above, 
> I have not seen any panics in my test lab setup in two days of load testing, 
> and AFAIK, packet capturing seems to be working fine.

Of course, the test system panic'ed with the same problem in catchpacket() an 
hour after I wrote this.

(kgdb) where
#0  doadump () at pcpu.h:224
#1  0x804c8280 in boot (howto=260) at ../../../kern/kern_shutdown.c:441
#2  0x804c8703 in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:614
#3  0x8069ffad in trap_fatal (frame=0x809edbc0, eva=Variable 
"eva" is not available.
)
at ../../../amd64/amd64/trap.c:825
#4  0x806a02e1 in trap_pfault (frame=0xff800014a8a0, usermode=0)
at ../../../amd64/amd64/trap.c:741
#5  0x806a06bf in trap (frame=0xff800014a8a0)
at ../../../amd64/amd64/trap.c:478
#6  0x80687cd4 in calltrap () at ../../../amd64/amd64/exception.S:228
#7  0x8069dc06 in bcopy () at ../../../amd64/amd64/support.S:124
#8  0x8056f69e in catchpacket (d=0xff005aaaf000, 
pkt=0xff0001f46200 "", pktlen=522, snaplen=Variable "snaplen" is not 
available.
) at ../../../net/bpf.c:2240
#9  0x8056fc66 in bpf_mtap (bp=0xff0001be8c80, 
m=0xff0001f46200) at ../../../net/bpf.c:2064
#10 0x80579c15 in ether_input (ifp=0xff0001b73800, 
m=0xff0001f46200) at ../../../net/if_ethersubr.c:635
#11 0x802b694a in em_rxeof (rxr=0xff0001bca200, count=99, done=0x0)
at ../../../dev/e1000/if_em.c:4404
#12 0x802b6db8 in em_handle_que (context=Variable "context" is not 
available.
)
at ../../../dev/e1000/if_em.c:1494
#13 0x80506d85 in taskqueue_run_locked (queue=0xff0001be1580)
at ../../../kern/subr_taskqueue.c:250
---Type  to continue, or q  to quit---q 
Quit
(kgdb) frame 8
#8  0x8056f69e in catchpacket (d=0xff005aaaf000, 
pkt=0xff0001f46200 "", pktlen=522, snaplen=Variable "snaplen" is not 
available.
) at ../../../net/bpf.c:2240
warning: Source file is more recent than executable.

2240bpf_append_bytes(d, d->bd_sbuf, curlen, &hdr, sizeof(hdr));
(kgdb) print *d
$1 = {bd_next = {le_next = 0xff0023fff400, le_prev = 0xff0001be8c90}, 
  bd_sbuf = 0x0, bd_hbuf = 0xff8000ffa000 "??~P", bd_fbuf = 0x0, 
  bd_slen = 0, bd_hlen = 2068, bd_bufsize = 8388608, 
  bd_bif = 0xff0001be8c80, bd_rtout = 1, bd_rfilter = 0xff0001e6f580, 
  bd_wfilter = 0x0, bd_bfilter = 0x0, bd_rcount = 7, bd_dcount = 0, 
  bd_promisc = 1 '\001', bd_state = 0 '\0', bd_immediate = 1 '\001', 
  bd_writer = 0 '\0', bd_hdrcmplt = 1, bd_direction = 1, bd_feedback = 0, 
  bd_async = 0, bd_sig = 23, bd_sigio = 0x0, bd_sel = {si_tdlist

Re: mpt irq timeout problem after reboot - only if non-verbose booting !?!

2012-10-17 Thread Harald Schmalzbauer 
 schrieb John Baldwin am 17.10.2012 19:19 (localtime):
> Are you using any RAID volumes?  The only shutdown handler in mpt that looks
> like it might want interrupts to work is mpt_raid_shutdown().  It needs to use
> polled I/O instead of disabling interrupts I think.  Try this:
>
> Index: mpt_raid.c
> ===
> --- mpt_raid.c(revision 241641)
> +++ mpt_raid.c(working copy)
> @@ -115,7 +115,7 @@ static timeout_t mpt_raid_timer;
>  static void mpt_enable_vol(struct mpt_softc *mpt,
>  struct mpt_raid_volume *mpt_vol, int enable);
>  #endif
> -static void mpt_verify_mwce(struct mpt_softc *, struct mpt_raid_volume *);
> +static void mpt_verify_mwce(struct mpt_softc *, struct mpt_raid_volume *, 
> int);
>  static void mpt_adjust_queue_depth(struct mpt_softc *, struct 
> mpt_raid_volume *,
>  struct cam_path *);
>  #if __FreeBSD_version < 50
> @@ -135,7 +135,7 @@ static void mpt_disk_prt(struct mpt_softc *mpt, st
>  static int mpt_issue_raid_req(struct mpt_softc *mpt,
>  struct mpt_raid_volume *vol, struct mpt_raid_disk *disk, request_t *req,
>  u_int Action, uint32_t ActionDataWord, bus_addr_t addr, bus_size_t len,
> -int write, int wait);
> +int write, int wait, int sleep_ok);
>  
>  static int mpt_refresh_raid_data(struct mpt_softc *mpt);
>  static void mpt_schedule_raid_refresh(struct mpt_softc *mpt);
> @@ -517,7 +517,7 @@ mpt_raid_shutdown(struct mpt_softc *mpt)
>  
>   mpt->raid_mwce_setting = MPT_RAID_MWCE_OFF;
>   RAID_VOL_FOREACH(mpt, mpt_vol) {
> - mpt_verify_mwce(mpt, mpt_vol);
> + mpt_verify_mwce(mpt, mpt_vol, FALSE);
>   }
>  }
>  
> @@ -592,7 +592,7 @@ static int
>  mpt_issue_raid_req(struct mpt_softc *mpt, struct mpt_raid_volume *vol,
>  struct mpt_raid_disk *disk, request_t *req, u_int Action,
>  uint32_t ActionDataWord, bus_addr_t addr, bus_size_t len,
> -int write, int wait)
> +int write, int wait, int sleep_ok)
>  {
>   MSG_RAID_ACTION_REQUEST *rap;
>   SGE_SIMPLE32 *se;
> @@ -623,7 +623,7 @@ mpt_issue_raid_req(struct mpt_softc *mpt, struct m
>  
>   if (wait) {
>   return (mpt_wait_req(mpt, req, REQ_STATE_DONE, REQ_STATE_DONE,
> -  /*sleep_ok*/FALSE, /*time_ms*/2000));
> +  sleep_ok, /*time_ms*/2000));
>   } else {
>   return (0);
>   }
> @@ -763,7 +763,7 @@ mpt_raid_quiesce_disk(struct mpt_softc *mpt, struc
>   MPI_RAID_ACTION_QUIESCE_PHYS_IO,
>   /*ActionData*/0, /*addr*/0,
>   /*len*/0, /*write*/FALSE,
> - /*wait*/FALSE);
> + /*wait*/FALSE, /*sleep_ok*/FALSE);
>   if (rv != 0)
>   return (CAM_REQ_CMP_ERR);
>  
> @@ -882,7 +882,7 @@ mpt_enable_vol(struct mpt_softc *mpt, struct mpt_r
>   enable ? MPI_RAID_ACTION_ENABLE_VOLUME
>  : MPI_RAID_ACTION_DISABLE_VOLUME,
>   /*data*/0, /*addr*/0, /*len*/0,
> - /*write*/FALSE, /*wait*/TRUE);
> + /*write*/FALSE, /*wait*/TRUE, /*sleep_ok*/TRUE);
>   if (rv == ETIMEDOUT) {
>   mpt_vol_prt(mpt, mpt_vol, "mpt_enable_vol: "
>   "%s Volume Timed-out\n",
> @@ -903,7 +903,8 @@ mpt_enable_vol(struct mpt_softc *mpt, struct mpt_r
>  #endif
>  
>  static void
> -mpt_verify_mwce(struct mpt_softc *mpt, struct mpt_raid_volume *mpt_vol)
> +mpt_verify_mwce(struct mpt_softc *mpt, struct mpt_raid_volume *mpt_vol,
> +int sleep_ok)
>  {
>   request_t *req;
>   struct mpt_raid_action_result *ar;
> @@ -950,7 +951,7 @@ static void
>   return;
>   }
>  
> - req = mpt_get_request(mpt, /*sleep_ok*/TRUE);
> + req = mpt_get_request(mpt, sleep_ok);
>   if (req == NULL) {
>   mpt_vol_prt(mpt, mpt_vol,
>   "mpt_verify_mwce: Get request failed!\n");
> @@ -965,7 +966,7 @@ static void
>   rv = mpt_issue_raid_req(mpt, mpt_vol, /*disk*/NULL, req,
>   MPI_RAID_ACTION_CHANGE_VOLUME_SETTINGS,
>   data, /*addr*/0, /*len*/0,
> - /*write*/FALSE, /*wait*/TRUE);
> + /*write*/FALSE, /*wait*/TRUE, sleep_ok);
>   if (rv == ETIMEDOUT) {
>   mpt_vol_prt(mpt, mpt_vol, "mpt_verify_mwce: "
>   "Write Cache Enable Timed-out\n");
> @@ -1018,7 +1019,8 @@ mpt_verify_resync_rate(struct mpt_softc *mpt, stru
>   rv = mpt_issue_raid_req(mpt, mpt_vol, /*disk*/NULL, req,
>   MPI_RAID_ACTION_SET_RESYNC_RATE,
>