Re: Can't compile ath(4) into kernel
On 8/25/2010 8:27 AM, John Baldwin wrote: > You are missing: > > options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors > But I don't have the ar5416 chipset... Mine is AR2312... And it is an option, so should not it be optional? Anyway, I tried adding that option and the error is the same (did cleandepend && depend, saw ah.c recompiled anew). > For the 6.x -> 8 upgrade you are doing, I strongly suggest looking at the > changes to GENERIC across your upgrade. It would save you several e-mails to > the mailing list Thanks, I did that. After several attempts to fiddle with options/devices, the wireless section now looks like: # Wireless NIC cards device wlan# 802.11 support options IEEE80211_DEBUG # enable debug msgs options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's options IEEE80211_SUPPORT_MESH # enable 802.11s draft support device wlan_wep# 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device ath device ath_rate_sample # SampleRate tx rate control for ath device ath_ar5212 #device ath_rate_onoe #optionsAH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors Generic simply uses the entire ath_hal, but ath_hal(4) suggests, that picking out a single driver should work... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kernel MCA messages
on 25/08/2010 18:02 Andriy Gapon said the following: > on 25/08/2010 15:23 John Baldwin said the following: >> That is because machine checks for corrected errors have to be polled and >> the >> kernel polls once an hour. On newer Intel CPUs (such as Nehalem) there is a >> separate interrupt (CMCI) that can fire for corrected errors. > > I think that on AMD it's possible to configure an interrupt for Bank 4 events > as > well (perhaps other banks too), but I need to refresh my memory of BKDG. Yeah, for Bank 4 only, configurable via MSR_0413 and MSRC000_04[0A:08] Machine Check Misc 4 (Thresholding) Registers. Also, see section 2.12.1.6 Error Thresholding in Fam10h BKDG. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kernel MCA messages
on 25/08/2010 15:23 John Baldwin said the following: > That is because machine checks for corrected errors have to be polled and the > kernel polls once an hour. On newer Intel CPUs (such as Nehalem) there is a > separate interrupt (CMCI) that can fire for corrected errors. I think that on AMD it's possible to configure an interrupt for Bank 4 events as well (perhaps other banks too), but I need to refresh my memory of BKDG. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kernel MCA messages
On Wednesday, August 25, 2010 7:01:19 am Andriy Gapon wrote: > on 25/08/2010 13:41 Dan Langille said the following: > > On 8/25/2010 3:11 AM, Andriy Gapon wrote: > > > >> Have you read the decoded message? > >> Please re-read it. > >> > >> I still recommend reading at least the summary of the RAM ECC research > >> article > >> to make your own judgment about need to replace DRAM. > > > > Andriy: What is your interpretation of the decoded message? What is your > > view on > > replacing DRAM? What do you conclude from the summary? > > Most likely you have a small defect in one of your memory modules, perhaps a > "stuck" bit. You will be getting correctable ECC errors for that module. > Eventually you might get uncorrectable error. That may happen soon or it may > never happen during lifetime of that modules. > > As that study has demonstrated a significant percentage of systems and modules > report at least one correctable ECC error. ECC correctable errors at present > correlate with correctable ECC errors in the future. They also correlate with > uncorrectable errors in the future. But percentage of systems developing > uncorrectable errors is significantly smaller, so chances of false positives > are > substantial. > > You should decide whether you want to replace the module (if you can pinpoint > it) > or all modules depending on your resources (money, etc), importance of service > that the server in question provides (allowable downtime and cost of it and > fault-tolerance of a larger system, of which the server may be a part (e.g. > it may > have a standby server for failover). > > I think that most of what I've just said was kind of obvious from the start. > The important bit from that study is that ECC errors are not as random and as > rare > as was previously thought, and they can be attributed to a number of factors > like > manufacturing defects, layout of memory lanes on motherboard, etc. A while back I found a slide deck from some Intel presentation that claimed that a modern 4GB DIMM should average 18 corrected errors a month. Your rate is a bit higher than that, but corrected ECC errors are not that unexpected. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Can't compile ath(4) into kernel
On Wednesday, August 25, 2010 12:39:40 am Mikhail T. wrote: > My laptop's kernel config file reads: > > device wlan# 802.11 support > device ath > device ath_ar5212 > device ath_rate_onoe > > Config raises no objections and the compilation succeeds, but linking > the kernel breaks: > > ... > linking kernel.debug > ah.o(.text+0x218): In function `ath_hal_rfprobe': > /home/mi/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to > `__start_set_ah_rfs' > ah.o(.text+0x21d):/home/mi/src/sys/dev/ath/ath_hal/ah.c:142: > undefined reference to `__stop_set_ah_rfs' > ah.o(.text+0x236):/home/mi/src/sys/dev/ath/ath_hal/ah.c:142: > undefined reference to `__stop_set_ah_rfs' > *** Error code 1 > > What could this be? All modules (including ath_hal) build correctly... > Thank you! You are missing: options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors For the 6.x -> 8 upgrade you are doing, I strongly suggest looking at the changes to GENERIC across your upgrade. It would save you several e-mails to the mailing list. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kernel MCA messages
On Tuesday, August 24, 2010 7:13:23 pm Dan Langille wrote: > On 8/22/2010 9:18 PM, Dan Langille wrote: > > What does this mean? > > > > kernel: MCA: Bank 4, Status 0x940c4001fe080813 > > kernel: MCA: Global Cap 0x0105, Status 0x > > kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 > > kernel: MCA: CPU 0 COR BUSLG Source RD Memory > > kernel: MCA: Address 0x7ff6b0 > > > > FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 > > FYI, these are occurring every hour, almost to the second. e.g. > xx:56:yy, where yy is 09, 10, or 11. > > Checking logs, I don't see anything that correlates with this point in > the hour (i.e 56 minutes past) that doesn't also occur at other times. > > It seems very odd to occur so regularly. That is because machine checks for corrected errors have to be polled and the kernel polls once an hour. On newer Intel CPUs (such as Nehalem) there is a separate interrupt (CMCI) that can fire for corrected errors. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kernel MCA messages
On Wednesday, August 25, 2010 12:05:09 am Matthew D. Fuller wrote: > On Tue, Aug 24, 2010 at 11:06:43AM -0400 I heard the voice of > John Baldwin, and lo! it spake thus: > > > > It is actually public at perforce.freebsd.org. :) However, it is > > tedious to download the files. > > Oh, I'd apparently blocked out of my mind that you could clicky-clicky > files one at a time from there. Probably for the best; I'd be real > annoyed by the end of that ;) > > > > You can find a patch at www.freebsd.org/~jhb/mcelog/. You will also > > need to download the memstream.c file from there as well and put > > that in the extracted mcelog tarball. > > Thanks! For anyone following along at home, I needed to make a few > changes to get it compiling here: > > - I'm on a nice recent -CURRENT, so I had to #if 0 out the getline() > definition. Yeah, that needs a __FreeBSD_version wrapper. > - Add a FREEBSD definition to the Makefile (or remember it manually). I just do 'gmake FREEBSD=yes'. > - Comment out the kread_symbol() of X_SNAPDATE in mcelog.c. I don't > see X_SNAPDATE defined anywhere in my /usr/include, and the var > doesn't seem to ever actually be read for anything anyway (unless > I'm supposed to -DLOCAL_HACK...). Bah, I must have missed that. You certainly don't want LOCAL_HACK. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Can't compile ath(4) into kernel
My laptop's kernel config file reads: device wlan# 802.11 support device ath device ath_ar5212 device ath_rate_onoe Config raises no objections and the compilation succeeds, but linking the kernel breaks: ... linking kernel.debug ah.o(.text+0x218): In function `ath_hal_rfprobe': /home/mi/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__start_set_ah_rfs' ah.o(.text+0x21d):/home/mi/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' ah.o(.text+0x236):/home/mi/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' *** Error code 1 What could this be? All modules (including ath_hal) build correctly... Thank you! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kernel MCA messages
on 25/08/2010 13:41 Dan Langille said the following: > On 8/25/2010 3:11 AM, Andriy Gapon wrote: > >> Have you read the decoded message? >> Please re-read it. >> >> I still recommend reading at least the summary of the RAM ECC research >> article >> to make your own judgment about need to replace DRAM. > > Andriy: What is your interpretation of the decoded message? What is your > view on > replacing DRAM? What do you conclude from the summary? Most likely you have a small defect in one of your memory modules, perhaps a "stuck" bit. You will be getting correctable ECC errors for that module. Eventually you might get uncorrectable error. That may happen soon or it may never happen during lifetime of that modules. As that study has demonstrated a significant percentage of systems and modules report at least one correctable ECC error. ECC correctable errors at present correlate with correctable ECC errors in the future. They also correlate with uncorrectable errors in the future. But percentage of systems developing uncorrectable errors is significantly smaller, so chances of false positives are substantial. You should decide whether you want to replace the module (if you can pinpoint it) or all modules depending on your resources (money, etc), importance of service that the server in question provides (allowable downtime and cost of it and fault-tolerance of a larger system, of which the server may be a part (e.g. it may have a standby server for failover). I think that most of what I've just said was kind of obvious from the start. The important bit from that study is that ECC errors are not as random and as rare as was previously thought, and they can be attributed to a number of factors like manufacturing defects, layout of memory lanes on motherboard, etc. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kernel MCA messages
On 8/25/2010 3:11 AM, Andriy Gapon wrote: Have you read the decoded message? Please re-read it. I still recommend reading at least the summary of the RAM ECC research article to make your own judgment about need to replace DRAM. Andriy: What is your interpretation of the decoded message? What is your view on replacing DRAM? What do you conclude from the summary? -- Dan Langille - http://langille.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kernel MCA messages
On Tue, Aug 24, 2010 at 4:06 PM, John Baldwin wrote: > On Monday, August 23, 2010 5:35:40 pm Matthew D. Fuller wrote: >> On Mon, Aug 23, 2010 at 08:20:35AM -0400 I heard the voice of >> John Baldwin, and lo! it spake thus: >> > >> > It is not private, it is in //depot/projects/mcelog/... in p4. >> >> Which may as well be Siberia for us lowly non-developers. Any chance >> you could stick a tarball or a patch against upstream mcelog >> somewhere? > > It is actually public at perforce.freebsd.org. :) However, it is tedious to > download the files. It really should be a port perhaps, though Someone (tm) > should try to get the patches integrated upstream. > > You can find a patch at www.freebsd.org/~jhb/mcelog/. You will also need to > download the memstream.c file from there as well and put that in the extracted > mcelog tarball. > I wrote a small script a while back to extract a tree from perforce using the web interface, might be handy: http://www.clearchain.com/~benjsc/downloads/FreeBSD/P4fetch.rb Cheers Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: typo error in /etc/defaults/rc.conf
Fixed. Thanks for the patch. On Wed, 25 Aug 2010, 11:05+0300, Bojidara Marinchovska wrote: > Hello , > > Refers to rc.conf(5) the alternative way for cloning interfaces is by using > create_args_ variable > In rc.conf there is a typo error in variable name > > > --- /etc/defaults/rc.conf.orig 2010-08-25 11:01:12.0 +0300 > +++ /etc/defaults/rc.conf 2010-08-25 11:01:29.0 +0300 > @@ -212,7 +212,7 @@ > #ifconfig_ed0_ipx="ipx 0x00010010" # Sample IPX address family entry. > #ifconfig_fxp0_name="net0" # Change interface name from fxp0 to net0. > #vlans_fxp0="101 vlan0"# vlan(4) interfaces for fxp0 device > -#create_arg_vlan0="vlan 102" # vlan tag for vlan0 device > +#create_args_vlan0="vlan 102" # vlan tag for vlan0 device > #wlans_ath0="wlan0"# wlan(4) interfaces for ath0 device > #wlandebug_wlan0="scan+auth+assoc" # Set debug flags with wlanddebug(8) > #ipv4_addrs_fxp0="192.168.0.1/24 192.168.1.1-5/28" # example IPv4 > address entry. > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Maxim Konovalov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zfs sharenfs with multiple hosts/networks and options
On 25.08.2010, at 10:03, Marco van Tol wrote: > On Wed, Aug 25, 2010 at 09:47:13AM +0200, Heinrich Rebehn wrote: >> Hi list, >> >> with traditional /etc/exports i can do >> >> /export/linux/root -ro xxx.xxx.xxx.0/24 >> /export/linux/root -maproot=0 xxx.xxx.xxx.1 >> >> How can i do this using zfs's sharenfs option? >> >> When i try >> >> zfs set sharenfs="-ro -network xxx.xxx.xxx.0/24,-maproot=0 xxx.xxx.xxx.1" >> data/linux/root >> >> /var/log/messages shows "network/host conflict" and "bad exports list line. >> >> The general problem seems to be that with each "zfs set sharenfs" command, >> the corresponding in /etc/zfs/exports gets overwritten. >> >> Is there a workaround for this besides ignoring sharenfs and using hand >> edited /etc/exports? >> >> Thanks for any help, > > In december '09 I started a thread about it in freebsd...@. > Subject: zfs sharenfs to multiple subnets - found a dirty looking hack > > I found a dirty hack to do what you need there. Not sure there is a > more elegant way to do it already, would be nice. > > Marco I already found your hack (after starting this thread) and it does work. However, when i then use zfs to create a descendant filesystem, things go wrong because when inheriting the sharenfs property from the parent, zfs does not adjust the mountpoint that i used in the hack. Similar problems will probably arise if one choses to change the mountpoint of the filesystem afterwards. Thanks anyway for the hint! -Heinrich > > -- > Now watch me snatch defeat from the jaws of victory > - "Rigoletto" during a game on www.dailygammon.com > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > Heinrich Rebehn University of Bremen Physics / Electrical and Electronics Engineering - Department of Telecommunications - Phone : +49/421/218-62394 Fax :-3341 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
typo error in /etc/defaults/rc.conf
Hello , Refers to rc.conf(5) the alternative way for cloning interfaces is by using create_args_ variable In rc.conf there is a typo error in variable name --- /etc/defaults/rc.conf.orig 2010-08-25 11:01:12.0 +0300 +++ /etc/defaults/rc.conf 2010-08-25 11:01:29.0 +0300 @@ -212,7 +212,7 @@ #ifconfig_ed0_ipx="ipx 0x00010010" # Sample IPX address family entry. #ifconfig_fxp0_name="net0" # Change interface name from fxp0 to net0. #vlans_fxp0="101 vlan0"# vlan(4) interfaces for fxp0 device -#create_arg_vlan0="vlan 102" # vlan tag for vlan0 device +#create_args_vlan0="vlan 102" # vlan tag for vlan0 device #wlans_ath0="wlan0"# wlan(4) interfaces for ath0 device #wlandebug_wlan0="scan+auth+assoc" # Set debug flags with wlanddebug(8) #ipv4_addrs_fxp0="192.168.0.1/24 192.168.1.1-5/28" # example IPv4 address entry. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zfs sharenfs with multiple hosts/networks and options
On Wed, Aug 25, 2010 at 09:47:13AM +0200, Heinrich Rebehn wrote: > Hi list, > > with traditional /etc/exports i can do > > /export/linux/root-ro xxx.xxx.xxx.0/24 > /export/linux/root-maproot=0 xxx.xxx.xxx.1 > > How can i do this using zfs's sharenfs option? > > When i try > > zfs set sharenfs="-ro -network xxx.xxx.xxx.0/24,-maproot=0 xxx.xxx.xxx.1" > data/linux/root > > /var/log/messages shows "network/host conflict" and "bad exports list line. > > The general problem seems to be that with each "zfs set sharenfs" command, > the corresponding in /etc/zfs/exports gets overwritten. > > Is there a workaround for this besides ignoring sharenfs and using hand > edited /etc/exports? > > Thanks for any help, In december '09 I started a thread about it in freebsd...@. Subject: zfs sharenfs to multiple subnets - found a dirty looking hack I found a dirty hack to do what you need there. Not sure there is a more elegant way to do it already, would be nice. Marco -- Now watch me snatch defeat from the jaws of victory - "Rigoletto" during a game on www.dailygammon.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
zfs sharenfs with multiple hosts/networks and options
Hi list, with traditional /etc/exports i can do /export/linux/root -ro xxx.xxx.xxx.0/24 /export/linux/root -maproot=0 xxx.xxx.xxx.1 How can i do this using zfs's sharenfs option? When i try zfs set sharenfs="-ro -network xxx.xxx.xxx.0/24,-maproot=0 xxx.xxx.xxx.1" data/linux/root /var/log/messages shows "network/host conflict" and "bad exports list line. The general problem seems to be that with each "zfs set sharenfs" command, the corresponding in /etc/zfs/exports gets overwritten. Is there a workaround for this besides ignoring sharenfs and using hand edited /etc/exports? Thanks for any help, Heinrich Rebehn University of Bremen Physics / Electrical and Electronics Engineering - Department of Telecommunications - Phone : +49/421/218-62394 Fax :-3341 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kernel MCA messages
on 25/08/2010 02:38 Jeremy Chadwick said the following: > On Tue, Aug 24, 2010 at 07:13:23PM -0400, Dan Langille wrote: >> On 8/22/2010 9:18 PM, Dan Langille wrote: >>> What does this mean? >>> >>> kernel: MCA: Bank 4, Status 0x940c4001fe080813 >>> kernel: MCA: Global Cap 0x0105, Status 0x >>> kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 >>> kernel: MCA: CPU 0 COR BUSLG Source RD Memory >>> kernel: MCA: Address 0x7ff6b0 >>> >>> FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 >> >> FYI, these are occurring every hour, almost to the second. e.g. >> xx:56:yy, where yy is 09, 10, or 11. >> >> Checking logs, I don't see anything that correlates with this point >> in the hour (i.e 56 minutes past) that doesn't also occur at other >> times. >> >> It seems very odd to occur so regularly. I still think that everything of essence has already been said in this thread. > 1) Why haven't you replaced the DIMM in Bank 4 -- or better yet, all Bank 4 here is MCA reporting bank, it has nothing to do with RAM slots. Currently on FreeBSD we don't have a standard tool to map physical address to DRAM module, but I am sure that there could be some ways to do it. >the DIMMs just to be sure? Do this and see if the problem goes >away. If not, no harm done, and you've narrowed it down. > > 2) What exact manufacturer and model of motherboard is this? If >you can provide a link to a User Manual that would be great. > > 3) Please go into your system BIOS and find where "ECC ChipKill" >options are available (likely under a Memory, Chipset, or >Northbridge section). Please write down and provide here all >of the options and what their currently selected values are. > > 4) Please make sure you're running the latest system BIOS. I've seen >on certain Rackable AMD-based systems where Northbridge-related >features don't work quite right (at least with Solaris), resulting >in atrocious memory performance on the system. A BIOS upgrade >solved the problem. > > There's a ChipKill feature called "ECC BG Scrubbing" that's vague in > definition, given that it's a "background memory scrub" that happens at > intervals which are unknown to me. Maybe 60 minutes? I don't know. > This is why I ask question #3. > > For John and other devs: I assume the decoded MCA messages indicate with > absolute certainty that the ECC error is coming from external DRAM and > not, say, bad L1 or L2 cache? Have you read the decoded message? Please re-read it. I still recommend reading at least the summary of the RAM ECC research article to make your own judgment about need to replace DRAM. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
cone segmentation fault on 8.0-STABLE amd64
Hi all, I'm running cone on 8.0-STABLE. When I run the program for the first time it works like a charm! Cone then creates a configuration directory and conerc. When I run cone the second time it crashed with a segmentation fault. Then after removing the "OPTIONS" node from the config file cone starts again. When I go to the setup menu and hit "save" also crashes with segfault. Any ideas? Cheers, Mark conerc: x...@ signature.asc Description: OpenPGP digital signature
