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-requ...@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-requ...@freebsd.org > >You can reach the person managing the list at >freebsd-stable-ow...@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 < me...@bris.ac.uk > >To: freebsd-curr...@freebsd.org, freebsd-stable@freebsd.org >Subject: urtwn regression(?) from 10.2 to current r291431 >Message-ID: < 201512061414.tb6eepty041...@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 < h...@selasky.org > >To: me...@bris.ac.uk, freebsd-curr...@freebsd.org, >freebsd-stable@freebsd.org, Adrian Chadd < adr...@freebsd.org > >Subject: Re: urtwn regression(?) from 10.2 to current r291431 >Message-ID: < 5664472e.3090...@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 < me...@bris.ac.uk > >To: adr...@freebsd.org, freebsd-curr...@freebsd.org, >freebsd-stable@freebsd.org, h...@selasky.org, me...@bris.ac.uk >Subject: Re: urtwn regression(?) from 10.2 to current r291431 >Message-ID: < 201512061444.tb6eipmm041...@mech-as222.men.bris.ac.uk > > >>From h...@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 < mmitc...@gmail.com > >To: me...@bris.ac.uk >Cc: adr...@freebsd.org, freebsd-curr...@freebsd.org, >freebsd-stable@freebsd.org, h...@selasky.org >Subject: Re: urtwn regression(?) from 10.2 to current r291431 >Message-ID: < 77a4dce9-d720-416a-a7ee-c97ee5195...@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 < me...@bris.ac.uk > wrote: >> >>> From h...@selasky.org <mailto: h...@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-curr...@freebsd.org <mailto: freebsd-curr...@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-unsubscr...@freebsd.org >> <mailto: freebsd-current-unsubscr...@freebsd.org >" > > > >------------------------------ > >Message: 5 >Date: Sun, 6 Dec 2015 09:29:43 -0800 >From: Adrian Chadd < adr...@freebsd.org > >To: Michael Mitchell < mmitc...@gmail.com >, >" freebsd-wirel...@freebsd.org " < freebsd-wirel...@freebsd.org >, Andriy >Voskoboinyk < s3er...@gmail.com > >Cc: Anton Shterenlikht < me...@bris.ac.uk >, freebsd-current >< freebsd-curr...@freebsd.org >, FreeBSD Stable Mailing List >< freebsd-stable@freebsd.org >, Hans Petter Selasky < h...@selasky.org > >Subject: Re: urtwn regression(?) from 10.2 to current r291431 >Message-ID: >< CAJ-Vmo=TgxO=bg3w1uq-me+9cymx+0klz2mdgnaspe_rva5...@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 < mmitc...@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 < me...@bris.ac.uk > wrote: >> >> From h...@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-curr...@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to " freebsd-current-unsubscr...@freebsd.org " >> >> > > >------------------------------ > >Message: 6 >Date: Sat, 05 Dec 2015 19:06:00 -0800 >From: per...@pluto.rain.com (Perry Hutchison) >To: freebsd-stable@freebsd.org >Subject: ICH5 ATA DMA timeouts >Message-ID: < 5663a618.157gxarwixdeyml8%per...@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 > r...@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 < kostik...@gmail.com > >To: Gavin Mu < gavin...@qq.com > >Cc: freebsd-stable < freebsd-stable@freebsd.org > >Subject: Re: application coredump behavior differences between FreeBSD >7.0andFreeBSD 10.1 >Message-ID: < 20151206193917.gh2...@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...@qq.com >; >> Date: Sun, Dec 6, 2015 08:14 AM >> To: "Konstantin Belousov"< kostik...@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";< kostik...@gmail.com >; >> Date: Sat, Dec 5, 2015 10:24 PM >> To: "Gavin Mu"< gavin...@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 >> > r...@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";< kostik...@gmail.com >; >> > Date: Fri, Dec 4, 2015 05:45 PM >> > To: "Gavin Mu"< gavin...@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 < kill...@multiplay.co.uk > >To: freebsd-stable@freebsd.org >Subject: Re: ICH5 ATA DMA timeouts >Message-ID: < 5664a6df.80...@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 >> r...@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-unsubscr...@freebsd.org " > > > >------------------------------ > >Message: 9 >Date: Sun, 06 Dec 2015 23:10:16 +0100 >From: Florian Ermisch < florian.ermi...@alumni.tu-berlin.de > >To: per...@pluto.rain.com,freebsd-stable@freebsd.org >Subject: Re: ICH5 ATA DMA timeouts >Message-ID: < 845edbe2-8111-4bfc-9ebe-abdbe7a0f...@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 < >kill...@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 >> > r...@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-unsubscr...@freebsd.org " >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> " freebsd-stable-unsubscr...@freebsd.org " > > > >------------------------------ > >Message: 10 >Date: Mon, 7 Dec 2015 11:51:14 +0100 >From: Johan Hendriks < joh.hendr...@gmail.com > >To: freebsd-stable@freebsd.org >Subject: jiberish output in mail from cron >Message-ID: < 566564a2.3030...@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-unsubscr...@freebsd.org " > >------------------------------ > >End of freebsd-stable Digest, Vol 646, Issue 1 >********************************************** _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
