Re: FS hang with suspfs when creating snapshot on a UFS + GJOURNAL setup
On Fri, Dec 28, 2012 at 01:27:24PM +0200, Konstantin Belousov wrote: > Please try the following patch. It is against HEAD, might need some > adjustments for 8. I do the resume and write accounting atomically, > not allowing other suspension to intervent between. So is this only limited to snapshot creation, or can it happen during some other relatively heavy disk activity, e.g. trying to build/install two ports simultaneously? Because I have just experienced a very similar hang - not sure about 'suspfs' though (couldn't run top). ___ 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: msk0: interrupt storm
On Wed, Apr 25, 2012 at 09:35:28AM -0400, John Baldwin wrote: > Sadly, I spoke too soon. With this patch applied I got another storm last > night > where this bit was not set during the storm: > > index cpu timestamptrace > -- --- - > 71 0 36775451301480 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 > 70 0 36775450145436 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 > 69 0 36775449956940 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 > 68 0 36775449768564 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 > 67 0 36775448604912 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 > 66 0 36775448416872 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 > 65 0 36775448220444 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 > 64 0 36775446569772 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 > 63 0 36775445385804 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 > 62 0 36775445189340 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 > 61 0 36775444984476 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 > 60 0 36775443829368 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 > 59 0 36775443640920 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 > 58 0 36775443444324 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 > 57 0 36775442272836 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 > > Apr 24 14:50:53 pipkin kernel: mskc0: TWSI ready > Apr 24 14:50:54 pipkin kernel: mskc0: TWSI ready > Apr 24 20:19:49 pipkin kernel: interrupt storm detected on "irq257:"; > throttling interrupt source > Apr 24 21:40:14 pipkin kernel: interrupt storm detected on "irq257:"; > throttling interrupt source > Apr 25 05:19:31 pipkin kernel: interrupt storm detected on "irq257:"; > throttling interrupt source > Apr 25 08:04:38 pipkin kernel: interrupt storm detected on "irq257:"; > throttling interrupt source > > (This trace was from the storm at 20:19:49.) Same here, I just fired up rtorrent and immediately got a storm accompanied by a 2 minute freeze: irq259: mskc06062100 8772 irq261: ahci0 8380 12 Total6427430 9301 ___ 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: msk0: interrupt storm
On Fri, Mar 02, 2012 at 10:05:54AM -0800, YongHyeon PYUN wrote: > Still have no idea. Would you post dmesg output? Sure, just let me know if you need anything else. Now running with hw.msk.msi_disable=1 hw.msk.jumbo_disable=1 still getting the storms, the above settings just seem to make them less severe/often. > If you know how to reproduce the issue, let me know. Any network activity will do, sometimes even just fetching new mail from pop.gmail.com via POP3 over SSL. So here's the dmesg as well as some other relevant bits: $ vmstat -i interrupt total rate irq9: acpi0 81 0 irq16: mskc0 uhci0 4419739456 irq17: cbb0 fwohci+ 6085 0 irq18: uhci2 ehci0+2 0 irq20: hpet0 4333544447 irq23: uhci3 ehci132 0 irq257: hdac0 1 0 irq258: hdac1 36 0 irq260: ahci0 169843 17 Total8929363921 ### currently configured with -rxcsum, ### but it doesn't seem to make any difference $ ifconfig msk0 msk0: flags=8843 metric 0 mtu 1500 options=c011a ether 00:17:42:c8:2a:2f inet 192.168.1.3 netmask 0xff00 broadcast 192.168.1.255 inet6 fe80::217:42ff:fec8:2a2f%msk0 prefixlen 64 scopeid 0x5 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active $ dmesg Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz (2261.05-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0xbfebfbff Features2=0x8e3fd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 3221225472 (3072 MB) avail memory = 3068252160 (2926 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x2000-0x20ff mem 0xf000-0xf7ff,0xfa00-0xfa00 irq 16 at device 0.0 on pci1 drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) info: [drm] Initialized radeon 1.31.0 20080613 hdac0: mem 0xfa01-0xfa013fff irq 17 at device 0.1 on pci1 uhci0: port 0x1800-0x181f irq 16 at device 26.0 on pci0 usbus0: on uhci0 uhci1: port 0x1820-0x183f irq 17 at device 26.1 on pci0 usbus1: on uhci1 uhci2: port 0x1840-0x185f irq 18 at device 26.2 on pci0 usbus2: on uhci2 ehci0: mem 0xfa704800-0xfa704bff irq 18 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3: on ehci0 hdac1: mem 0xfa70-0xfa703fff irq 22 at device 27.0 on pci0 pcib2: irq 17 at device 28.0 on pci0 pci8: on pcib2 mskc0: port 0x3000-0x30ff mem 0xfa10-0xfa103fff irq 16 at device 0.0 on pci8 msk0: on mskc0 msk0: disabling jumbo frame support msk0: Ethernet address: 00:17:42:c8:2a:2f miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow pcib3: irq 16 at device 28.1 on pci0 pci16: on pcib3 pcib4: irq 18 at device 28.2 on pci0 pci24: on pcib4 iwn0: mem 0xfa20-0xfa201fff irq 18 at device 0.0 on pci24 pcib5: irq 19 at device 28.3 on pci0 pci32: on pcib5 pci32: at device 0.0 (no driver attached) uhci3: port 0x1860-0x187f irq 23 at device 29.0 on pci0 usbus4: on uhci3 uhci4: port 0x1880-0x189f irq 19 at device 29.1 on pci0 usbus5: on uhci4 uhci5: port 0x18a0-0x18bf irq 18 at device 29.2 on pci0 usbus6: on uhci5 ehci1: mem 0xfa704c00-0xfa704fff irq 23 at device 29.7 on pci0 usbus7: EHCI version 1.0 usbus7: on ehci1 pcib6: at device 30.0 on pci0 pci56: on pcib6 cbb0: irq 17 at device 3.0 on pci56 cardbus0: on cbb0 pccard0: <16-bit PCCa
Re: msk0: interrupt storm
On Thu, Mar 01, 2012 at 05:29:55PM -0800, YongHyeon PYUN wrote: > On Wed, Feb 29, 2012 at 01:03:29AM +0400, Pavel Gorshkov wrote: > > My laptop running 9.0-RELEASE/amd64/GENERIC freezes and > > (sometimes) unfreezes intermittently, logging the following: > > > > Feb 28 23:07:36 lifebook kernel: interrupt storm detected on "irq259:"; > > throttling interrupt source > > > > $ vmstat -i > > ... > > irq259: mskc0 11669511 3456 > > > > > > Looks very similar to this: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=164569 > > > > Any suggestions? > > Try disabling MSI and see whether that makes any difference. hw.msk.msi_disable is not recognized as a valid sysctl variable and I'm not sure about it having any effect whatsoever, but putting hw.msk.msi_disable=1 into /boot/loader.conf seems to have resulted in this: irq16: mskc0 uhci0355402884 that is, msk0 is now on irq16, but the freezes are still there: Mar 1 23:55:12 lifebook kernel: interrupt storm detected on "irq16:"; throttling interrupt source ___ 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"
msk0: interrupt storm
My laptop running 9.0-RELEASE/amd64/GENERIC freezes and (sometimes) unfreezes intermittently, logging the following: Feb 28 23:07:36 lifebook kernel: interrupt storm detected on "irq259:"; throttling interrupt source $ vmstat -i ... irq259: mskc0 11669511 3456 Looks very similar to this: http://www.freebsd.org/cgi/query-pr.cgi?pr=164569 Any suggestions? ___ 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: Freebsd 8.1 + xorg + radeonhd hang
On Mon, Sep 13, 2010 at 11:47:18PM +0200, Eivind E wrote: > Yeah, still hangs hard. Trying the normal radeon driver together > with Option "DRI" "False" as suggested to me in another mail > did let X start up once, but set the screen to much darker > colours (which also continued when exiting). Starting X > another time again made the machine hang again. You might want to try putting the following line into the appropriate "Device" section: Option "AccelMethod" "EXA" ___ 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"
powerd (-adp/-hadp) strangeness on 7.2/amd64
Every time I create/mount or unmount/detach a MFS filesystem, powerd would *immediately* react with something like the following: ### mdmfs -s 200m md /mfs load 200%, current freq 600 MHz ( 9), wanted freq 1092 MHz changing clock speed from 600 MHz to 1200 MHz load 4%, current freq 1200 MHz ( 5), wanted freq 955 MHz changing clock speed from 1200 MHz to 1000 MHz ### umount /mfs && mdconfig -d -u 0 load 200%, current freq 1000 MHz ( 6), wanted freq 1910 MHz changing clock speed from 1000 MHz to 1982 MHz or even load 4%, current freq 1600 MHz ( 3), wanted freq 1519 MHz ### mdmfs here load 100%, current freq 1600 MHz ( 3), wanted freq 4532 MHz Is that expected behaviour? :-) ___ 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: SHA1_Update() produces wrong results for large buffers
On Tue, Jan 10, 2006 at 02:10:33PM +1100, Peter Jeremy wrote:
> I get this on 7-current as well. Copying the relevant bits from libmd
> and compiling it myself, I get the same behaviour. The fact that this
> exits virtually instantly strongly suggests that it is broken (rather
> than the shared version). My initial guess is that an operation on
> the length is overflowing 32 bits. Unfortunately, the asm is rather
> opaque - it was auto-generated by a perl script that doesn't seem to
> included in the repository. (There is a sha1-586.pl in openssl but
> it generates different code).
Yes, the SHA1 implementation in libmd.a is very similar to the one
found in libcrypto.a, the former is just much older.
SHA1_Update as provided by libcrypto.a has no problems with large
buffers. Here's a slightly modified test program (attached), now
compatible with -lcrypto:
gcc sha1test.c -o sha1test.ssl-static -lcrypto -static
gcc sha1test.c -o sha1test.md-shared -lmd
gcc sha1test.c -o sha1test.md-static -lmd -static
dd if=/dev/zero bs=32M count=48 of=test-1.5G
for i in ssl-static md-{shared,static}; do ./sha1test.$i test-1.5G; done
a957f01b1a92366c7b72296cb24eb84f42ed06e4
a957f01b1a92366c7b72296cb24eb84f42ed06e4
747cd7172ce7737d1735cf936c0d69ce0f733fcd
According to this page:
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libmd/i386/
our version of `sha.S' is 6 years old, whereas `sha1-586.pl' as
found in the openssl cvs tree has underwent many changes since
then:
http://cvs.openssl.org/rlog?f=openssl/crypto/sha/asm/sha1-586.pl
> As far as I can determine, the asm code (sha1_block_x86) is designed
> to process an integral number of SHA1 blocks of input, leaving the
> remainder to be processed in the C code. Using the debugger, the
> asm code is not looping when passed 1610612736 (1.5G) - which explains
> the rapid exit and incorrect result.
Yes, thanks for the additional info.
It looks like some parts of libmd should be either fixed/brought
in sync with the openssl cvs, or marked as deprecated.
Peter & Simon, thanks for confirming the test results.
--
Pavel Gorshkov
#include
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char **argv) {
int fd, i;
struct stat st;
SHA_CTX ctx;
unsigned char *buf, digest[20];
char hexdigest[41];
if (argc < 2 || stat(argv[1], &st) < 0 || (fd=open(argv[1], O_RDONLY)) < 0)
exit(1);
if ((buf = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0)) ==
MAP_FAILED)
exit(1);
SHA1_Init(&ctx);
SHA1_Update(&ctx, buf, st.st_size);
SHA1_Final(digest, &ctx);
for (i = 0; i < 20; ++i)
sprintf(hexdigest + 2*i, "%02x", digest[i]);
puts(hexdigest);
if (st.st_size)
munmap(buf, st.st_size);
close(fd);
return 0;
}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SHA1_Update() produces wrong results for large buffers
An important detail to begin with is that our libmd.a, as opposed
to libmd.so, provides a faster, assembly-optimized version of the
`SHA1_Update' function (it is not compatible with PIC and is
therefore not used in libmd.so).
The problem is that the asm-optimized version fails on large input
buffers. Attached is a test program, which mmaps a file and then
just feeds its contents to SHA1_Update():
gcc sha1test.c -o sha1test.md-shared -lmd
gcc sha1test.c -o sha1test.md-static -lmd -static
the input files:
dd if=/dev/zero bs=32M count=48 of=test-1.5G
dd if=/dev/zero bs=32M count=32 of=test-1G
dd if=/dev/zero bs=32M count=16 of=test-0.5G
***
# exits immediately, displaying a WRONG hash value
./sha1test.md-static test-1.5G
747cd7172ce7737d1735cf936c0d69ce0f733fcd
# OK
./sha1test.md-shared test-1.5G
a957f01b1a92366c7b72296cb24eb84f42ed06e4
***
./sha1test.md-static test-1G
0d6ee6083bf8b6368cb80d323e82164e5540e296
# ^^^ WRONG
# OK
./sha1test.md-shared test-1G
2a492f15396a6768bcbca016993f4b4c8b0b5307
However, both programs work fine with files less than ~920M:
./sha1test.md-static test-0.5G
5b088492c9f4778f409b7ae61477dec124c99033
./sha1test.md-shared test-0.5G
5b088492c9f4778f409b7ae61477dec124c99033
Everything was tested on a RELENG_6/i386 box (CFLAGS = -O2).
Is this a bug in libmd, or am I missing something?
Thanks in advance,
--
Pavel Gorshkov
#include
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char **argv) {
int fd;
struct stat st;
SHA_CTX ctx;
unsigned char *buf;
char hexdigest[41];
if (argc < 2 || stat(argv[1], &st) < 0 || (fd=open(argv[1], O_RDONLY)) < 0)
exit(1);
if ((buf = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0)) ==
MAP_FAILED)
exit(1);
SHA1_Init(&ctx);
SHA1_Update(&ctx, buf, st.st_size);
SHA1_End(&ctx, hexdigest);
puts(hexdigest);
if (st.st_size)
munmap(buf, st.st_size);
close(fd);
return 0;
}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
