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 at
freebsd.org:
>
>Send freebsd-stable mailing list submissions to
>freebsd-stable at 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 at freebsd.org
>
>You can reach the person managing the list at
>freebsd-stable-owner at 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 at bris.ac.uk >
>To: freebsd-current at freebsd.org, freebsd-stable at freebsd.org
>Subject: urtwn regression(?) from 10.2 to current r291431
>Message-ID: < 201512061414.tB6EEpTY041098 at 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 at selasky.org >
>To: mexas at bris.ac.uk, freebsd-current at freebsd.org,
>freebsd-stable at freebsd.org, Adrian Chadd < adrian at freebsd.org >
>Subject: Re: urtwn regression(?) from 10.2 to current r291431
>Message-ID: < 5664472E.3090601 at 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 at bris.ac.uk >
>To: adrian at freebsd.org, freebsd-current at freebsd.org,
>freebsd-stable at freebsd.org, hps at selasky.org, mexas at bris.ac.uk
>Subject: Re: urtwn regression(?) from 10.2 to current r291431
>Message-ID: < 201512061444.tB6EiPmm041204 at mech-as222.men.bris.ac.uk
>
>
>>From hps at 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 at gmail.com >
>To: mexas at bris.ac.uk
>Cc: adrian at freebsd.org, freebsd-current at freebsd.org,
>freebsd-stable at freebsd.org, hps at selasky.org
>Subject: Re: urtwn regression(?) from 10.2 to current r291431
>Message-ID: < 77A4DCE9-D720-416A-A7EE-C97EE5195E20 at 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 at bris.ac.uk
> wrote:
>>
>>> From hps at selasky.org <mailto: hps at 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 at freebsd.org <mailto: freebsd-current at
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 at
freebsd.org <mailto: freebsd-current-unsubscribe at freebsd.org >"
>
>
>
>------------------------------
>
>Message: 5
>Date: Sun, 6 Dec 2015 09:29:43 -0800
>From: Adrian Chadd < adrian at freebsd.org >
>To: Michael Mitchell < mmitchel at gmail.com >,
>" freebsd-wireless at freebsd.org " < freebsd-wireless at
freebsd.org >, Andriy
>Voskoboinyk < s3erios at gmail.com >
>Cc: Anton Shterenlikht < mexas at bris.ac.uk >, freebsd-current
>< freebsd-current at freebsd.org >, FreeBSD Stable Mailing List
>< freebsd-stable at freebsd.org >, Hans Petter Selasky < hps at
selasky.org >
>Subject: Re: urtwn regression(?) from 10.2 to current r291431
>Message-ID:
>< CAJ-Vmo=TgxO=Bg3w1uq-ME+9Cymx+0kLZ2mdGnAspE_rVA5Q0Q at 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 at 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 at bris.ac.uk
> wrote:
>>
>> From hps at 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 at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to " freebsd-current-unsubscribe at
freebsd.org "
>>
>>
>
>
>------------------------------
>
>Message: 6
>Date: Sat, 05 Dec 2015 19:06:00 -0800
>From: perryh at pluto.rain.com (Perry Hutchison)
>To: freebsd-stable at freebsd.org
>Subject: ICH5 ATA DMA timeouts
>Message-ID: < 5663a618.157GXarwIXDEyml8%perryh at 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 at 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 at gmail.com >
>To: Gavin Mu < gavin.mu at qq.com >
>Cc: freebsd-stable < freebsd-stable at freebsd.org >
>Subject: Re: application coredump behavior differences between FreeBSD
>7.0andFreeBSD 10.1
>Message-ID: < 20151206193917.GH2202 at 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 at qq.com >;
>> Date: Sun, Dec 6, 2015 08:14 AM
>> To: "Konstantin Belousov"< kostikbel at gmail.com >;
>> Cc: "freebsd-stable"< freebsd-stable at 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 at gmail.com
>;
>> Date: Sat, Dec 5, 2015 10:24 PM
>> To: "Gavin Mu"< gavin.mu at qq.com >;
>> Cc: "freebsd-stable"< freebsd-stable at 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 at
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 at gmail.com
>;
>> > Date: Fri, Dec 4, 2015 05:45 PM
>> > To: "Gavin Mu"< gavin.mu at qq.com >;
>> > Cc: "freebsd-stable"< freebsd-stable at 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 at multiplay.co.uk >
>To: freebsd-stable at freebsd.org
>Subject: Re: ICH5 ATA DMA timeouts
>Message-ID: < 5664A6DF.80205 at 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 at 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 at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to " freebsd-stable-unsubscribe at
freebsd.org "
>
>
>
>------------------------------
>
>Message: 9
>Date: Sun, 06 Dec 2015 23:10:16 +0100
>From: Florian Ermisch < florian.ermisch at alumni.tu-berlin.de >
>To: perryh at pluto.rain.com,freebsd-stable at freebsd.org
>Subject: Re: ICH5 ATA DMA timeouts
>Message-ID: < 845EDBE2-8111-4BFC-9EBE-ABDBE7A0FC53 at 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 at
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 at 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 at freebsd.org mailing list
>> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> > To unsubscribe, send any mail to
>> " freebsd-stable-unsubscribe at freebsd.org "
>>
>> _______________________________________________
>> freebsd-stable at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to
>> " freebsd-stable-unsubscribe at freebsd.org "
>
>
>
>------------------------------
>
>Message: 10
>Date: Mon, 7 Dec 2015 11:51:14 +0100
>From: Johan Hendriks < joh.hendriks at gmail.com >
>To: freebsd-stable at freebsd.org
>Subject: jiberish output in mail from cron
>Message-ID: < 566564A2.3030507 at 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 at rsnapshot-2015-11-20 from Fri Nov 20
>21:02 2015
>
>: SNIP : about 50 lines
>
>DELETE: storage/rsnapshot/dmo1 at rsnapshot-2015-11-20 from Fri Nov 20
>21:02 2015
>DELETE:
>storage/rsnap?hot/demo2 at 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
at rsnapshot-2015-11-20>from Fri Nov 20 21:02 2015
>DELETE: storage/rsnapshot/demo2 at rsnapshot-2015-11-20 from Fri Nov 20
>21:02 2015
>DELETE: storage/rsnapshot/demo3 at rsnapshot-2015-11-20 from Fri Nov 20
>21:02 2015
>DELETE: storage/rsnapshot/demo4 at rsnapshot-2015-11-20 from Fri Nov 20
>21:03 2015
>DELETE: storage/rsnapshot/demo5 at rsnapshot-2015-11-20 from Fri Nov 20
>21:03 2015
>DELETE: storage/rsnapshot/demo6 at 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 at freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>To unsubscribe, send any mail to " freebsd-stable-unsubscribe at
freebsd.org "
>
>------------------------------
>
>End of freebsd-stable Digest, Vol 646, Issue 1
>**********************************************