Re: 8.3: kernel panic in bpf.c catchpacket()
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
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 !?!
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
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 !?!
-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
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
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
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?
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?
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()
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 !?!
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, >