Date: Mon, 07 Dec 2015 22:04:24 +0300 From: =?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JTQvtC70LHQvdC40L0=?= <bad_hdd@list.ru> To: =?UTF-8?B?ZnJlZWJzZC1zdGFibGU=?= <freebsd-stable@freebsd.org> Subject: =?UTF-8?B?SUNINSBBVEEgRE1BIHRpbWVvdXRz?= Message-ID: <1449515064.901077675@f356.i.mail.ru> In-Reply-To: <mailman.9.1449489600.81642.freebsd-stable@freebsd.org> References: <mailman.9.1449489600.81642.freebsd-stable@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Good day everyone ! First of all I would advise you to change all of your hard drives interface cables with new ones. >Понедельник, 7 декабря 2015, 12:00 UTC от freebsd-stable-request@freebsd.org: > >Send freebsd-stable mailing list submissions to >freebsd-stable@freebsd.org > >To subscribe or unsubscribe via the World Wide Web, visit >https://lists.freebsd.org/mailman/listinfo/freebsd-stable >or, via email, send a message with subject or body 'help' to >freebsd-stable-request@freebsd.org > >You can reach the person managing the list at >freebsd-stable-owner@freebsd.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of freebsd-stable digest..." > > >Today's Topics: > > 1. urtwn regression(?) from 10.2 to current r291431 > (Anton Shterenlikht) > 2. Re: urtwn regression(?) from 10.2 to current r291431 > (Hans Petter Selasky) > 3. Re: urtwn regression(?) from 10.2 to current r291431 > (Anton Shterenlikht) > 4. Re: urtwn regression(?) from 10.2 to current r291431 > (Michael Mitchell) > 5. Re: urtwn regression(?) from 10.2 to current r291431 > (Adrian Chadd) > 6. ICH5 ATA DMA timeouts (Perry Hutchison) > 7. Re: application coredump behavior differences between FreeBSD > 7.0andFreeBSD 10.1 (Konstantin Belousov) > 8. Re: ICH5 ATA DMA timeouts (Steven Hartland) > 9. Re: ICH5 ATA DMA timeouts (Florian Ermisch) > 10. jiberish output in mail from cron (Johan Hendriks) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Sun, 06 Dec 2015 06:14:52 -0800 (PST) >From: Anton Shterenlikht < mexas@bris.ac.uk > >To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org >Subject: urtwn regression(?) from 10.2 to current r291431 >Message-ID: < 201512061414.tB6EEpTY041098@mech-as222.men.bris.ac.uk > > >I posted this about a week ago: > >http://lists.freebsd.org/pipermail/freebsd-current/2015-November/058683.html > >The problem is that urtwn stopped >working in current r291431. > >I did more testing with the same revision, >and sometimes it would work, but extremely >slowly, and sometimes seemingly associate >but get an address of 0.0.0.0. > >I now installed 10.2-RELEASE-p8 and >the urtwn works fine, no issues at all. > >Does this look like a bug at some recent >current revision? Should I file a PR? > >I's just I recall there have been major >chages to wlan, so perphaps I'm forgetting >to change the config in recent current? > >Please advise > >Anton > > >------------------------------ > >Message: 2 >Date: Sun, 6 Dec 2015 15:33:18 +0100 >From: Hans Petter Selasky < hps@selasky.org > >To: mexas@bris.ac.uk, freebsd-current@freebsd.org, >freebsd-stable@freebsd.org, Adrian Chadd < adrian@freebsd.org > >Subject: Re: urtwn regression(?) from 10.2 to current r291431 >Message-ID: < 5664472E.3090601@selasky.org > >Content-Type: text/plain; charset=windows-1252; format=flowed > >On 12/06/15 15:14, Anton Shterenlikht wrote: >> I posted this about a week ago: >> >> http://lists.freebsd.org/pipermail/freebsd-current/2015-November/058683.html >> >> The problem is that urtwn stopped >> working in current r291431. >> >> I did more testing with the same revision, >> and sometimes it would work, but extremely >> slowly, and sometimes seemingly associate >> but get an address of 0.0.0.0. >> >> I now installed 10.2-RELEASE-p8 and >> the urtwn works fine, no issues at all. >> >> Does this look like a bug at some recent >> current revision? Should I file a PR? >> >> I's just I recall there have been major >> chages to wlan, so perphaps I'm forgetting >> to change the config in recent current? >> >> Please advise >> >> Anton > >Hi, > >There is work ongoing in the WLAN drivers. Did you try the latest -current? > >--HPS > > > >------------------------------ > >Message: 3 >Date: Sun, 06 Dec 2015 06:44:26 -0800 (PST) >From: Anton Shterenlikht < mexas@bris.ac.uk > >To: adrian@freebsd.org, freebsd-current@freebsd.org, >freebsd-stable@freebsd.org, hps@selasky.org, mexas@bris.ac.uk >Subject: Re: urtwn regression(?) from 10.2 to current r291431 >Message-ID: < 201512061444.tB6EiPmm041204@mech-as222.men.bris.ac.uk > > >>From hps@selasky.org Sun Dec 6 14:41:27 2015 >> >>On 12/06/15 15:14, Anton Shterenlikht wrote: >>> I posted this about a week ago: >>> >>> http://lists.freebsd.org/pipermail/freebsd-current/2015-November/058683.html >>> >>> The problem is that urtwn stopped >>> working in current r291431. >>> >>> I did more testing with the same revision, >>> and sometimes it would work, but extremely >>> slowly, and sometimes seemingly associate >>> but get an address of 0.0.0.0. >>> >>> I now installed 10.2-RELEASE-p8 and >>> the urtwn works fine, no issues at all. >>> >>> Does this look like a bug at some recent >>> current revision? Should I file a PR? >>> >>> I's just I recall there have been major >>> chages to wlan, so perphaps I'm forgetting >>> to change the config in recent current? >>> >>> Please advise >>> >>> Anton >> >>Hi, >> >>There is work ongoing in the WLAN drivers. Did you try the latest -current? >> >>--HPS > >r291431 was about a week ago. >Will try latest -current later today. > >Anton > > > >------------------------------ > >Message: 4 >Date: Sun, 6 Dec 2015 08:25:04 -0800 >From: Michael Mitchell < mmitchel@gmail.com > >To: mexas@bris.ac.uk >Cc: adrian@freebsd.org, freebsd-current@freebsd.org, >freebsd-stable@freebsd.org, hps@selasky.org >Subject: Re: urtwn regression(?) from 10.2 to current r291431 >Message-ID: < 77A4DCE9-D720-416A-A7EE-C97EE5195E20@gmail.com > >Content-Type: text/plain; charset=us-ascii > >i pulled the recent RPI2 r291495 from ftp.freebsd.org, and i also notice that the urtwn usb dongle >i typically use is very flakey with -CURRENT on the Raspberry Pi 2. The symptoms sound very >similar to those described on this thread. > >: mdm > >> On Dec 6, 2015, at 6:44 AM, Anton Shterenlikht < mexas@bris.ac.uk > wrote: >> >>> From hps@selasky.org <mailto: hps@selasky.org > Sun Dec 6 14:41:27 2015 >>> >>> On 12/06/15 15:14, Anton Shterenlikht wrote: >>>> I posted this about a week ago: >>>> >>>> http://lists.freebsd.org/pipermail/freebsd-current/2015-November/058683.html >>>> >>>> The problem is that urtwn stopped >>>> working in current r291431. >>>> >>>> I did more testing with the same revision, >>>> and sometimes it would work, but extremely >>>> slowly, and sometimes seemingly associate >>>> but get an address of 0.0.0.0. >>>> >>>> I now installed 10.2-RELEASE-p8 and >>>> the urtwn works fine, no issues at all. >>>> >>>> Does this look like a bug at some recent >>>> current revision? Should I file a PR? >>>> >>>> I's just I recall there have been major >>>> chages to wlan, so perphaps I'm forgetting >>>> to change the config in recent current? >>>> >>>> Please advise >>>> >>>> Anton >>> >>> Hi, >>> >>> There is work ongoing in the WLAN drivers. Did you try the latest -current? >>> >>> --HPS >> >> r291431 was about a week ago. >> Will try latest -current later today. >> >> Anton >> >> _______________________________________________ >> freebsd-current@freebsd.org <mailto: freebsd-current@freebsd.org > mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current < https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to " freebsd-current-unsubscribe@freebsd.org <mailto: freebsd-current-unsubscribe@freebsd.org >" > > > >------------------------------ > >Message: 5 >Date: Sun, 6 Dec 2015 09:29:43 -0800 >From: Adrian Chadd < adrian@freebsd.org > >To: Michael Mitchell < mmitchel@gmail.com >, >" freebsd-wireless@freebsd.org " < freebsd-wireless@freebsd.org >, Andriy >Voskoboinyk < s3erios@gmail.com > >Cc: Anton Shterenlikht < mexas@bris.ac.uk >, freebsd-current >< freebsd-current@freebsd.org >, FreeBSD Stable Mailing List >< freebsd-stable@freebsd.org >, Hans Petter Selasky < hps@selasky.org > >Subject: Re: urtwn regression(?) from 10.2 to current r291431 >Message-ID: >< CAJ-Vmo=TgxO=Bg3w1uq-ME+9Cymx+0kLZ2mdGnAspE_rVA5Q0Q@mail.gmail.com > >Content-Type: text/plain; charset=UTF-8 > >hiya, > >+wireless, +andriy > >Andriy has been working on adding lots of new things to urtwn and >tidying it up. It's possible he's introduced some regressions. Just >check in on the wireless list and join #freebsd-wireless on efnet to >ask questions. > >Hopefully it was fixed a couple days ago with the TX fixes he did; >otherwise he has more work cut out for him. :) > >Thanks for reporting the regressions so quickly! > > > >-a > > >On 6 December 2015 at 08:25, Michael Mitchell < mmitchel@gmail.com > wrote: >> i pulled the recent RPI2 r291495 from ftp.freebsd.org, and i also notice >> that the urtwn usb dongle >> i typically use is very flakey with -CURRENT on the Raspberry Pi 2. The >> symptoms sound very >> similar to those described on this thread. >> >> : mdm >> >> On Dec 6, 2015, at 6:44 AM, Anton Shterenlikht < mexas@bris.ac.uk > wrote: >> >> From hps@selasky.org Sun Dec 6 14:41:27 2015 >> >> On 12/06/15 15:14, Anton Shterenlikht wrote: >> >> I posted this about a week ago: >> >> http://lists.freebsd.org/pipermail/freebsd-current/2015-November/058683.html >> >> The problem is that urtwn stopped >> working in current r291431. >> >> I did more testing with the same revision, >> and sometimes it would work, but extremely >> slowly, and sometimes seemingly associate >> but get an address of 0.0.0.0. >> >> I now installed 10.2-RELEASE-p8 and >> the urtwn works fine, no issues at all. >> >> Does this look like a bug at some recent >> current revision? Should I file a PR? >> >> I's just I recall there have been major >> chages to wlan, so perphaps I'm forgetting >> to change the config in recent current? >> >> Please advise >> >> Anton >> >> >> Hi, >> >> There is work ongoing in the WLAN drivers. Did you try the latest -current? >> >> --HPS >> >> >> r291431 was about a week ago. >> Will try latest -current later today. >> >> Anton >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to " freebsd-current-unsubscribe@freebsd.org " >> >> > > >------------------------------ > >Message: 6 >Date: Sat, 05 Dec 2015 19:06:00 -0800 >From: perryh@pluto.rain.com (Perry Hutchison) >To: freebsd-stable@freebsd.org >Subject: ICH5 ATA DMA timeouts >Message-ID: < 5663a618.157GXarwIXDEyml8%perryh@pluto.rain.com > >Content-Type: text/plain; charset=us-ascii > >Does anyone know the condition of the ICH5 ATA support in FreeBSD 10? > >In preparing to repurpose an elderly Dell Dimension 4600 from Windows >to FreeBSD, and needing to decide what to do about drives, I found >several mentions in the archives* of ICH5 ATA DMA timeouts -- mostly >affecting the SATA ports, but the prevalence of SATA reports may >just indicate which ports were getting the most use: a couple of >the reports involved the PATA ports. > >While there have been commits to the ATA code since then, I didn't >find any definitive statement that the DMA timeouts had been fixed. >Did I miss something, or would I be better off using a separate SATA >or PATA PCI card instead of the ICH5's built-in ports? > >Relevant parts of dmesg (with no hard drives attached): > >FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 12 19:31:38 UTC 2015 > root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 >CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.06-MHz 686-class CPU) > Origin="GenuineIntel" Id=0xf34 Family=0xf Model=0x3 Stepping=4 > Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=0x441d<SSE3,DTES64,MON,DS_CPL,CNXT-ID,xTPR> > TSC: P-state invariant >uhci0: <Intel 82801EB (ICH5) USB controller USB-A> port 0xff80-0xff9f irq 16 at device 29.0 on pci0 >usbus0 on uhci0 >uhci1: <Intel 82801EB (ICH5) USB controller USB-B> port 0xff60-0xff7f irq 19 at device 29.1 on pci0 >usbus1 on uhci1 >uhci2: <Intel 82801EB (ICH5) USB controller USB-C> port 0xff40-0xff5f irq 18 at device 29.2 on pci0 >usbus2 on uhci2 >uhci3: <Intel 82801EB (ICH5) USB controller USB-D> port 0xff20-0xff3f irq 16 at device 29.3 on pci0 >usbus3 on uhci3 >ehci0: <Intel 82801EB/R (ICH5) USB 2.0 controller> mem 0xffa80800-0xffa80bff irq 23 at device 29.7 on pci0 >usbus4: EHCI version 1.0 >usbus4 on ehci0 >atapci0: <Intel ICH5 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf mem 0xfeb7fc00-0xfeb7ffff irq 18 at device 31.1 on pci0 >ata0: <ATA channel> at channel 0 on atapci0 >ata1: <ATA channel> at channel 1 on atapci0 >atapci1: <Intel ICH5 SATA150 controller> port 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfea0-0xfeaf irq 18 at device 31.2 on pci0 >ata2: <ATA channel> at channel 0 on atapci1 >ata3: <ATA channel> at channel 1 on atapci1 >pci0: <serial bus, SMBus> at device 31.3 (no driver attached) >pcm0: <Intel ICH5 (82801EB)> port 0xee00-0xeeff,0xedc0-0xedff mem 0xfeb7fa00-0xfeb7fbff,0xfeb7f900-0xfeb7f9ff irq 17 at device 31.5 on pci0 >pcm0: primary codec not ready! >pcm0: <Analog Devices AD1980 AC97 Codec (id = 0x41445370)> >ata0: reset tp1 mask=00 ostat0=ff ostat1=ff >ata1: reset tp1 mask=03 ostat0=00 ostat1=00 >ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb >ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb >ata1: reset tp2 stat0=00 stat1=00 devices=0x30000 >ata2: SATA reset: ports status=0x00 >ata2: p0: SATA connect timeout status=00000004 >ata3: SATA reset: ports status=0x00 >ata3: p0: SATA connect timeout status=00000004 >pass0 at ata1 bus 0 scbus1 target 0 lun 0 >pass0: <HL-DT-ST DVD-ROM GDR8163B 0D20> Removable CD-ROM SCSI device >pass0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) >pass1 at ata1 bus 0 scbus1 target 1 lun 0 >pass1: <HL-DT-ST CD-RW GCE-8483B B105> Removable CD-ROM SCSI device >pass1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) >cd0 at ata1 bus 0 scbus1 target 0 lun 0 >cd0: <HL-DT-ST DVD-ROM GDR8163B 0D20> Removable CD-ROM SCSI device >cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) >cd0: Attempt to query device size failed: NOT READY, Medium not present >cd1 at ata1 bus 0 scbus1 target 1 lun 0 >cd1: <HL-DT-ST CD-RW GCE-8483B B105> Removable CD-ROM SCSI device >cd1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) >cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed >GEOM: new disk cd0 >GEOM: new disk cd1 > >* Archive mentions, in http://lists.freebsd.org/pipermail/ ... > > freebsd-hardware/2004-September/thread.html#1924 > freebsd-current/2005-February/thread.html#46719 > freebsd-current/2005-February/thread.html#46737 > freebsd-stable/2005-March/thread.html#13265 > freebsd-stable/2007-May/thread.html#35061 > freebsd-stable/2007-July/thread.html#36308 > freebsd-bugs/2012-November/thread.html#50729 > > >------------------------------ > >Message: 7 >Date: Sun, 6 Dec 2015 21:39:17 +0200 >From: Konstantin Belousov < kostikbel@gmail.com > >To: Gavin Mu < gavin.mu@qq.com > >Cc: freebsd-stable < freebsd-stable@freebsd.org > >Subject: Re: application coredump behavior differences between FreeBSD >7.0andFreeBSD 10.1 >Message-ID: < 20151206193917.GH2202@kib.kiev.ua > >Content-Type: text/plain; charset=us-ascii > >On Sun, Dec 06, 2015 at 04:54:38PM +0800, Gavin Mu wrote: >> Hi, kib, >> >> >> It is really related with madvise behavior, I checked code related with MADV_SEQUENTIAL, and it seems there is something wrong with vm_fault() of FreeBSD 10.1. >> I did a simple patch: >> diff --git a/sys/vm/vm_fault.c b/sys/vm/vm_fault.c >> index b5ac58f..135fc67 100644 >> --- a/sys/vm/vm_fault.c >> +++ b/sys/vm/vm_fault.c >> @@ -966,6 +966,8 @@ vnode_locked: >> */ >> if (hardfault) >> fs.entry->next_read = fs.pindex + faultcount - reqpage; >> + else >> + fs.entry->next_read = fs.pindex + 1; >> >> >> vm_fault_dirty(fs.entry, fs.m, prot, fault_type, fault_flags, TRUE); >> vm_page_assert_xbusied(fs.m); >> >> >> >> without this next_read will not be updated and keeps zero in my testing. I think here next_read should be updated to be pindex + 1. Is my understanding correct? thanks. >> >Yes, I think you are right pointing out that soft faults are not >accounted for the read-ahead and cache-behind behaviour, and this >results in the pages behind the read point to be not deactivated. >OTOH, the behaviour of ignoring the soft faults is intentional, since >read-ahead (and cache-behind) should be only triggered when the pager is >executing costly i/o. > >I think that the right question to ask, which I did not asked in the >first reply, is why do you raised the behaviour as an issue ? Generally, >the fact that the pages of the shared segment are instantiated, mapped >and activated due to accesses (be it coredumping or any other reason) >is the expected VM behaviour. > >I do not think that the behaviour of the 7.x kernel in the specific >state, where most of the pages of the large shared segment are not >even instantiated, was intentional. It was a consequence of some other, >really undesirable, cache-behind configuration, I believe. Making >specific optimization for this case (i.e. not-instantiated pages of >the swap object accessed by the exiting process) is possible, but is >somewhat questionable. > >> >> Regards, >> Gavin Mu >> >> >> ------------------ Original ------------------ >> From: "Gavin Mu";< gavin.mu@qq.com >; >> Date: Sun, Dec 6, 2015 08:14 AM >> To: "Konstantin Belousov"< kostikbel@gmail.com >; >> Cc: "freebsd-stable"< freebsd-stable@freebsd.org >; >> Subject: Re: application coredump behavior differences between FreeBSD 7.0andFreeBSD 10.1 >> >> >> >> Hi, kib, >> >> >> It does not help. >> I added: >> ret = madvise(shm_handle, size * 1024 * 1024 * 1024, MADV_SEQUENTIAL); >> if (ret != 0) { >> printf("madvise return %d\n", ret); >> } >> >> >> >> top displays it still uses full memory, below is a snapshot during core dump. >> last pid: 3656; load averages: 1.84, 1.29, 1.04 up 0+00:18:06 23:58:37 >> 43 processes: 2 running, 41 sleeping >> CPU: 1.2% user, 0.0% nice, 85.2% system, 7.8% interrupt, 5.9% idle >> Mem: 924M Active, 57M Inact, 745M Wired, 8980K Cache, 103M Buf, 34M Free >> Swap: 4096M Total, 188M Used, 3908M Free, 4% Inuse >> >> >> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND >> 3646 root 1 84 0 1036M 710M RUN 0:13 42.29% tt >> >> >> >> Regards, >> Gavin Mu >> >> >> ------------------ Original ------------------ >> From: "Konstantin Belousov";< kostikbel@gmail.com >; >> Date: Sat, Dec 5, 2015 10:24 PM >> To: "Gavin Mu"< gavin.mu@qq.com >; >> Cc: "freebsd-stable"< freebsd-stable@freebsd.org >; >> Subject: Re: application coredump behavior differences between FreeBSD 7.0andFreeBSD 10.1 >> >> >> >> On Sat, Dec 05, 2015 at 01:09:31PM +0800, Gavin Mu wrote: >> > Hi, kib, >> > >> > >> > Please see my testing on FreeBSD 7.0. >> > freebsd7# sysctl kern.ipc.shmall >> > kern.ipc.shmall: 819200 >> > freebsd7# sysctl kern.ipc.shmmax >> > kern.ipc.shmmax: 3355443200 >> > freebsd7# uname -a >> > FreeBSD freebsd7.localdomain 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 10:35:36 UTC 2008 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >> > >> > >> > >> > testing code: >> > freebsd7# cat tt.c >> > #include <stdio.h> >> > #include <stdlib.h> >> > #include <machine/param.h> >> > #include <sys/types.h> >> > #include <sys/ipc.h> >> > #include <sys/shm.h> >> > >> > >> > int >> > main(int argc, char **argv) >> > { >> > char **p; >> > int size; >> > int i; >> > char *c = NULL; >> > int shmid; >> > void *shm_handle; >> > size = atoi(argv[1]); >> > printf("will alloc %dGB\n", size); >> > >> > >> > shmid = shmget(100, size * 1024 * 1024 * 1024, 0644 | IPC_CREAT); >> > if (shmid == -1) { >> > printf("shmid = %d\n", shmid); >> > } >> > >> > >> > shm_handle = shmat(shmid, NULL, 0); >> (shm_handle is not a handle). >> > if (shm_handle == -1) { >> > printf("null shm_handle\n"); >> > } >> > >> What if you add >> madvise(shm_handle, size, MADV_SEQUENTIAL); >> there ? Does 10.x behaviour become similar to that of the 7.x ? >> >> > >> > *c = 0; >> > return 0; >> > } >> > >> > >> > >> > freebsd7# ./a.out 1 >> > will alloc 1GB >> > Segmentation fault (core dumped) >> > >> > >> > >> > when a.out is running, the RES keeps being 2024K without increasing: >> > >> > >> > last pid: 735; load averages: 0.00, 0.01, 0.03 up 0+00:15:11 04:43:35 >> > 25 processes: 1 running, 24 sleeping >> > CPU states: 0.0% user, 0.0% nice, 22.6% system, 0.8% interrupt, 76.7% idle >> > Mem: 13M Active, 6380K Inact, 52M Wired, 32K Cache, 39M Buf, 910M Free >> > Swap: 2015M Total, 2015M Free >> > >> > >> > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND >> > 734 root 1 -16 0 1027M 2024K wdrain 0:02 13.27% a.out >> > >> > >> > >> > but when same code is running on FreeBSD 10.1, the RES keeps increasing to 1GB. From my testing, if the memory is allocated by malloc(), then RES will keep increasing in both 7.0 and 10.1. only sysv_shm in 7.0 has different behavior. I have checked coredump() code but did not find any clue why it is different. >> > >> > >> > Regards, >> > Gavin Mu >> > >> > >> > ------------------ Original ------------------ >> > From: "Konstantin Belousov";< kostikbel@gmail.com >; >> > Date: Fri, Dec 4, 2015 05:45 PM >> > To: "Gavin Mu"< gavin.mu@qq.com >; >> > Cc: "freebsd-stable"< freebsd-stable@freebsd.org >; >> > Subject: Re: application coredump behavior differences between FreeBSD 7.0and FreeBSD 10.1 >> > >> > >> > >> > On Fri, Dec 04, 2015 at 09:35:54AM +0800, Gavin Mu wrote: >> > > Hi, >> > > >> > > We have an application running on old FreeBSD 7.0, and we are upgrading the base system to FreeBSD 10.1. The application uses sysv_shm, and will allocate a lot of share memory, though most of time only a part of the allocated memory is used. aka. large SIZE and small RES from /usr/bin/top view. >> > > >> > > When the application core dump, the core dump file will be large, and in FreeBSD 7.0, it uses only a little more memory to do core dump, but in FreeBSD 10.1, it seems all share memory are touched and uses a lot of physical memory (RES in /usr/bin/top output will increase very much) and cause memory drain. >> > > >> > > I have been debugging but can not find any clue yet. Could someone provide some points where the issue happen? Thanks. >> > >> > Both stable/7 and latest HEAD do read the whole mapped segment to write >> > the coredump. This behaviour did not changed, since probably introduction >> > of the ELF support into FreeBSD. And, how otherwise could coredump file >> > contain the content of the mapped segments ? >> > >> > What in the FreeBSD 10 changed in this regard, is a deadlock fix which >> > could occur in some scenarious, including the coredumping. In stable/7, >> > the page instantiation or swap-in for pages accessed by the core write, >> > was done while owning several VFS locks. This sometimes caused deadlock. >> > In stable/10 the deadlock avoidance code is enabled by default, and >> > when kernel detects the possibility of the deadlock, it changes to reading >> > carefully by small chunks. >> > >> > Still, this does not explain the effect that you describe. In fact, I >> > am more suspicious to the claim that stable/7 did not increase RSS of >> > the dumping process or did not accessed the whole mapped shared segment, >> > then the claim that there is a regression in stable/10. > > >------------------------------ > >Message: 8 >Date: Sun, 6 Dec 2015 21:21:35 +0000 >From: Steven Hartland < killing@multiplay.co.uk > >To: freebsd-stable@freebsd.org >Subject: Re: ICH5 ATA DMA timeouts >Message-ID: < 5664A6DF.80205@multiplay.co.uk > >Content-Type: text/plain; charset=windows-1252; format=flowed > >Check cables and devices are in good condition. These things are usually >a connectivity issue or device failing > >On 06/12/2015 03:06, Perry Hutchison wrote: >> Does anyone know the condition of the ICH5 ATA support in FreeBSD 10? >> >> In preparing to repurpose an elderly Dell Dimension 4600 from Windows >> to FreeBSD, and needing to decide what to do about drives, I found >> several mentions in the archives* of ICH5 ATA DMA timeouts -- mostly >> affecting the SATA ports, but the prevalence of SATA reports may >> just indicate which ports were getting the most use: a couple of >> the reports involved the PATA ports. >> >> While there have been commits to the ATA code since then, I didn't >> find any definitive statement that the DMA timeouts had been fixed. >> Did I miss something, or would I be better off using a separate SATA >> or PATA PCI card instead of the ICH5's built-in ports? >> >> Relevant parts of dmesg (with no hard drives attached): >> >> FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 12 19:31:38 UTC 2015 >> root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 >> CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.06-MHz 686-class CPU) >> Origin="GenuineIntel" Id=0xf34 Family=0xf Model=0x3 Stepping=4 >> Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> >> Features2=0x441d<SSE3,DTES64,MON,DS_CPL,CNXT-ID,xTPR> >> TSC: P-state invariant >> uhci0: <Intel 82801EB (ICH5) USB controller USB-A> port 0xff80-0xff9f irq 16 at device 29.0 on pci0 >> usbus0 on uhci0 >> uhci1: <Intel 82801EB (ICH5) USB controller USB-B> port 0xff60-0xff7f irq 19 at device 29.1 on pci0 >> usbus1 on uhci1 >> uhci2: <Intel 82801EB (ICH5) USB controller USB-C> port 0xff40-0xff5f irq 18 at device 29.2 on pci0 >> usbus2 on uhci2 >> uhci3: <Intel 82801EB (ICH5) USB controller USB-D> port 0xff20-0xff3f irq 16 at device 29.3 on pci0 >> usbus3 on uhci3 >> ehci0: <Intel 82801EB/R (ICH5) USB 2.0 controller> mem 0xffa80800-0xffa80bff irq 23 at device 29.7 on pci0 >> usbus4: EHCI version 1.0 >> usbus4 on ehci0 >> atapci0: <Intel ICH5 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf mem 0xfeb7fc00-0xfeb7ffff irq 18 at device 31.1 on pci0 >> ata0: <ATA channel> at channel 0 on atapci0 >> ata1: <ATA channel> at channel 1 on atapci0 >> atapci1: <Intel ICH5 SATA150 controller> port 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfea0-0xfeaf irq 18 at device 31.2 on pci0 >> ata2: <ATA channel> at channel 0 on atapci1 >> ata3: <ATA channel> at channel 1 on atapci1 >> pci0: <serial bus, SMBus> at device 31.3 (no driver attached) >> pcm0: <Intel ICH5 (82801EB)> port 0xee00-0xeeff,0xedc0-0xedff mem 0xfeb7fa00-0xfeb7fbff,0xfeb7f900-0xfeb7f9ff irq 17 at device 31.5 on pci0 >> pcm0: primary codec not ready! >> pcm0: <Analog Devices AD1980 AC97 Codec (id = 0x41445370)> >> ata0: reset tp1 mask=00 ostat0=ff ostat1=ff >> ata1: reset tp1 mask=03 ostat0=00 ostat1=00 >> ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb >> ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb >> ata1: reset tp2 stat0=00 stat1=00 devices=0x30000 >> ata2: SATA reset: ports status=0x00 >> ata2: p0: SATA connect timeout status=00000004 >> ata3: SATA reset: ports status=0x00 >> ata3: p0: SATA connect timeout status=00000004 >> pass0 at ata1 bus 0 scbus1 target 0 lun 0 >> pass0: <HL-DT-ST DVD-ROM GDR8163B 0D20> Removable CD-ROM SCSI device >> pass0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) >> pass1 at ata1 bus 0 scbus1 target 1 lun 0 >> pass1: <HL-DT-ST CD-RW GCE-8483B B105> Removable CD-ROM SCSI device >> pass1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) >> cd0 at ata1 bus 0 scbus1 target 0 lun 0 >> cd0: <HL-DT-ST DVD-ROM GDR8163B 0D20> Removable CD-ROM SCSI device >> cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) >> cd0: Attempt to query device size failed: NOT READY, Medium not present >> cd1 at ata1 bus 0 scbus1 target 1 lun 0 >> cd1: <HL-DT-ST CD-RW GCE-8483B B105> Removable CD-ROM SCSI device >> cd1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) >> cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed >> GEOM: new disk cd0 >> GEOM: new disk cd1 >> >> * Archive mentions, in http://lists.freebsd.org/pipermail/ ... >> >> freebsd-hardware/2004-September/thread.html#1924 >> freebsd-current/2005-February/thread.html#46719 >> freebsd-current/2005-February/thread.html#46737 >> freebsd-stable/2005-March/thread.html#13265 >> freebsd-stable/2007-May/thread.html#35061 >> freebsd-stable/2007-July/thread.html#36308 >> freebsd-bugs/2012-November/thread.html#50729 >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to " freebsd-stable-unsubscribe@freebsd.org " > > > >------------------------------ > >Message: 9 >Date: Sun, 06 Dec 2015 23:10:16 +0100 >From: Florian Ermisch < florian.ermisch@alumni.tu-berlin.de > >To: perryh@pluto.rain.com,freebsd-stable@freebsd.org >Subject: Re: ICH5 ATA DMA timeouts >Message-ID: < 845EDBE2-8111-4BFC-9EBE-ABDBE7A0FC53@alumni.tu-berlin.de > >Content-Type: text/plain; charset=UTF-8 > >I had some onboard (S)ATA controllers becoming unreliable in the >past. Two of them due to chipsets overheating under load which >were fixable with additional cooling. In the third one we just added >a cheap SATA card and spread the redundant disks between >onboard and add-on controller to make a temporary failure a minor >issue. > >Regards, Florian > >Am 6. Dezember 2015 22:21:35 MEZ, schrieb Steven Hartland < killing@multiplay.co.uk >: >> Check cables and devices are in good condition. These things are >> usually >> a connectivity issue or device failing >> >> On 06/12/2015 03:06, Perry Hutchison wrote: >> > Does anyone know the condition of the ICH5 ATA support in FreeBSD >> 10? >> > >> > In preparing to repurpose an elderly Dell Dimension 4600 from >> Windows >> > to FreeBSD, and needing to decide what to do about drives, I found >> > several mentions in the archives* of ICH5 ATA DMA timeouts -- mostly >> > affecting the SATA ports, but the prevalence of SATA reports may >> > just indicate which ports were getting the most use: a couple of >> > the reports involved the PATA ports. >> > >> > While there have been commits to the ATA code since then, I didn't >> > find any definitive statement that the DMA timeouts had been fixed. >> > Did I miss something, or would I be better off using a separate SATA >> > or PATA PCI card instead of the ICH5's built-in ports? >> > >> > Relevant parts of dmesg (with no hard drives attached): >> > >> > FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 12 19:31:38 UTC 2015 >> > root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 >> > CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.06-MHz 686-class CPU) >> > Origin="GenuineIntel" Id=0xf34 Family=0xf Model=0x3 >> Stepping=4 >> > >> Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> >> > Features2=0x441d<SSE3,DTES64,MON,DS_CPL,CNXT-ID,xTPR> >> > TSC: P-state invariant >> > uhci0: <Intel 82801EB (ICH5) USB controller USB-A> port >> 0xff80-0xff9f irq 16 at device 29.0 on pci0 >> > usbus0 on uhci0 >> > uhci1: <Intel 82801EB (ICH5) USB controller USB-B> port >> 0xff60-0xff7f irq 19 at device 29.1 on pci0 >> > usbus1 on uhci1 >> > uhci2: <Intel 82801EB (ICH5) USB controller USB-C> port >> 0xff40-0xff5f irq 18 at device 29.2 on pci0 >> > usbus2 on uhci2 >> > uhci3: <Intel 82801EB (ICH5) USB controller USB-D> port >> 0xff20-0xff3f irq 16 at device 29.3 on pci0 >> > usbus3 on uhci3 >> > ehci0: <Intel 82801EB/R (ICH5) USB 2.0 controller> mem >> 0xffa80800-0xffa80bff irq 23 at device 29.7 on pci0 >> > usbus4: EHCI version 1.0 >> > usbus4 on ehci0 >> > atapci0: <Intel ICH5 UDMA100 controller> port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf mem >> 0xfeb7fc00-0xfeb7ffff irq 18 at device 31.1 on pci0 >> > ata0: <ATA channel> at channel 0 on atapci0 >> > ata1: <ATA channel> at channel 1 on atapci0 >> > atapci1: <Intel ICH5 SATA150 controller> port >> 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfea0-0xfeaf >> irq 18 at device 31.2 on pci0 >> > ata2: <ATA channel> at channel 0 on atapci1 >> > ata3: <ATA channel> at channel 1 on atapci1 >> > pci0: <serial bus, SMBus> at device 31.3 (no driver attached) >> > pcm0: <Intel ICH5 (82801EB)> port 0xee00-0xeeff,0xedc0-0xedff mem >> 0xfeb7fa00-0xfeb7fbff,0xfeb7f900-0xfeb7f9ff irq 17 at device 31.5 on >> pci0 >> > pcm0: primary codec not ready! >> > pcm0: <Analog Devices AD1980 AC97 Codec (id = 0x41445370)> >> > ata0: reset tp1 mask=00 ostat0=ff ostat1=ff >> > ata1: reset tp1 mask=03 ostat0=00 ostat1=00 >> > ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb >> > ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb >> > ata1: reset tp2 stat0=00 stat1=00 devices=0x30000 >> > ata2: SATA reset: ports status=0x00 >> > ata2: p0: SATA connect timeout status=00000004 >> > ata3: SATA reset: ports status=0x00 >> > ata3: p0: SATA connect timeout status=00000004 >> > pass0 at ata1 bus 0 scbus1 target 0 lun 0 >> > pass0: <HL-DT-ST DVD-ROM GDR8163B 0D20> Removable CD-ROM SCSI device >> > pass0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) >> > pass1 at ata1 bus 0 scbus1 target 1 lun 0 >> > pass1: <HL-DT-ST CD-RW GCE-8483B B105> Removable CD-ROM SCSI device >> > pass1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) >> > cd0 at ata1 bus 0 scbus1 target 0 lun 0 >> > cd0: <HL-DT-ST DVD-ROM GDR8163B 0D20> Removable CD-ROM SCSI device >> > cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) >> > cd0: Attempt to query device size failed: NOT READY, Medium not >> present >> > cd1 at ata1 bus 0 scbus1 target 1 lun 0 >> > cd1: <HL-DT-ST CD-RW GCE-8483B B105> Removable CD-ROM SCSI device >> > cd1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) >> > cd1: Attempt to query device size failed: NOT READY, Medium not >> present - tray closed >> > GEOM: new disk cd0 >> > GEOM: new disk cd1 >> > >> > * Archive mentions, in http://lists.freebsd.org/pipermail/ ... >> > >> > freebsd-hardware/2004-September/thread.html#1924 >> > freebsd-current/2005-February/thread.html#46719 >> > freebsd-current/2005-February/thread.html#46737 >> > freebsd-stable/2005-March/thread.html#13265 >> > freebsd-stable/2007-May/thread.html#35061 >> > freebsd-stable/2007-July/thread.html#36308 >> > freebsd-bugs/2012-November/thread.html#50729 >> > _______________________________________________ >> > freebsd-stable@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > To unsubscribe, send any mail to >> " freebsd-stable-unsubscribe@freebsd.org " >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> " freebsd-stable-unsubscribe@freebsd.org " > > > >------------------------------ > >Message: 10 >Date: Mon, 7 Dec 2015 11:51:14 +0100 >From: Johan Hendriks < joh.hendriks@gmail.com > >To: freebsd-stable@freebsd.org >Subject: jiberish output in mail from cron >Message-ID: < 566564A2.3030507@gmail.com > >Content-Type: text/plain; charset=utf-8 > >I am running cron jobs on multiple machines, and the output is mailed to >our support department. > >But the output contains some jiberish text. > >In this example is is from a cronjob that deletes some old snapshots. > >DELETE: storage/rsnapshot/custumor2@rsnapshot-2015-11-20 from Fri Nov 20 >21:02 2015 > >: SNIP : about 50 lines > >DELETE: storage/rsnapshot/dmo1@rsnapshot-2015-11-20 from Fri Nov 20 >21:02 2015 >DELETE: >storage/rsnap?hot/demo2@rsnapshot-2015-11-20 from Fri Nov 20 21:02 2015??2015????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????I??????????????????????????????@???????@??????????????????????@????????????????????????????????????????@??????????????O>???????????????????????????????????????= >???I?i0??]??????? >??????????????????????????????????????????????????$???H?????????0??????{??????????????????H???????????H?C?????????h?????????C???????????H??????C????????????????a????H?C?????C??????????? ???????????????????????B??????????@??????I8?????????? >?????? >??????M?`????????????`???????????4 ???(???????? ???(????????b????????????????????????M?`???????????????????h???????o >????????????????????????????????????????????????`??????P? >???????????8??????????????????????Rb???? ?????? >????????`??????b????? >?????????????????????????????????????????@???????Rb????????????????????`??????b????Q@??????????????? ?????b????????????b?????o >???h??????????????????????????????????? >b???????????,?`??????b????Q@??????????????? ?????b????????????b?????o >???h????????????????????h??????? b????? >b?????????????`????? >b??????b??????b??????b??????b????? >??????Q@??????????????? ?????b??????????????????????????h????????????????????????? ???????????????? >b????P????????`??????????h??????,@?????4#a????Q@?????Q@??????????????? ??????b?????????????b?????o >???h??????? b????P??????4#a?????o >???PL?????????? ?`????8??????????????`????? b????X??????????????????????????????????`E?????????????????????????????????????b????Fd?????????????????????????0?????????????m?`????I?i0??] ?????????????????????%??????0??????p???????L???#??????Fd???????????0????????shot/leisuregifts@rsnapshot-2015-11-20 >from Fri Nov 20 21:02 2015 >DELETE: storage/rsnapshot/demo2@rsnapshot-2015-11-20 from Fri Nov 20 >21:02 2015 >DELETE: storage/rsnapshot/demo3@rsnapshot-2015-11-20 from Fri Nov 20 >21:02 2015 >DELETE: storage/rsnapshot/demo4@rsnapshot-2015-11-20 from Fri Nov 20 >21:03 2015 >DELETE: storage/rsnapshot/demo5@rsnapshot-2015-11-20 from Fri Nov 20 >21:03 2015 >DELETE: storage/rsnapshot/demo6@rsnapshot-2015-11-20 from Fri Nov 20 >21:03 2015 > >Then again about 50 lines OK and then again some jiberish text and so on > >the cronjob is as follows. >0 8 * * * >/root/scripts/zfs-clean-snapshots.sh -d 14 -p rsnapshot-2015 > >I have this on multiple machines. >Is there a buffer I hit or something > >regards, >Johan > > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >freebsd-stable@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to " freebsd-stable-unsubscribe@freebsd.org " > >------------------------------ > >End of freebsd-stable Digest, Vol 646, Issue 1 >**********************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1449515064.901077675>