Re: ath0: lot of bad series hwrate and AH_SUPPORT_AR5416
On 30/11/2010 00:25, Adrian Chadd wrote: (I should get me an AR9285 to test with at some point.) On 29 November 2010 18:52, David DEMELIERdemelier.da...@gmail.com wrote: ath0: bad series3 hwrate 0x1b, tries 2 ts_status 0x0 ath0: bad series3 hwrate 0x1b, tries 2 ts_status 0x0 ath0: bad series3 hwrate 0x1b, tries 2 ts_status 0x0 ath0: bad series3 hwrate 0x1b, tries 2 ts_status 0x0 That's ath_rate_sample saying I don't know about that hardware rate, but it transmitted successfully! So something queued up a patcket at that hwrate. 0x1B is CCK_1MB_L - that should be fine in 11bg? Or is this somehow running in 11A mode? Would you please paste 'ifconfig wlan0' here? mark...@melon ~ $ ifconfig wlan0 wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether c4:17:fe:c4:14:b9 inet 130.79.183.186 netmask 0xfc00 broadcast 130.79.183.255 media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g status: associated ssid osiris-sec channel 11 (2462 MHz 11g) bssid 00:26:99:23:69:23 regdomain 106 indoor ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpower 20 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL bintval 102 I also don't understand why the option AH_SUPPORT_AR5416 is needed in kernel, I found this http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006417.html and it should include it if the driver needs it, isn't it? Here my kernel won't build if I remove it so I have : options AH_SUPPORT_AR5416 device ath device ath_hal device ath_rate_sample Would you please file a PR for that and email me the PR number? PR as :kern/152736 Thanks, adrian ___ 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: Anfrage von Kundennummer KK-57776
Guten Tag Kundennummer KK-57776, die erste Woche im Dezember steht vor uns. Nehmen Sie sich 1 Minute Zeit um den Traif Ihrer Krankenkasse zu vergleichen. 2011 ändern sich fast alle Tarife und Leistungen. Durch einen Vergleich der privaten Krankenkasse können Sie 190,00 Euro und mehr im Monat(!) sparen. Oft erhalten Sie sogar mehr Leistungen als vorher, und zahlen auch noch weniger dafür. Nutzen Sie unseren Vergleich - es dauert nur 1 Minute. Kostenlos und unverbindlich: http://c.optimal-2011.net/k-504-5587908.htm Wir freuen uns Ihnen zu helfen. Ihre Andrea Müller Sie erhalten dieses E-Mailing, da Sie uns oder einem unserer Partner Ihre Einwilligung dazu gegeben haben. Gerne können Sie Ihre E-Mail Adresse löschen. Klicken Sie dazu einfach hier: http://c.optimal-2011.net/a/?i=7297192e=stable%40freebsd.orgc=5587908 ___ 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: ath0: lot of bad series hwrate and AH_SUPPORT_AR5416
On 1 December 2010 18:11, David Demelier demelier.da...@gmail.com wrote: Or is this somehow running in 11A mode? Would you please paste 'ifconfig wlan0' here? mark...@melon ~ $ ifconfig wlan0 wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether c4:17:fe:c4:14:b9 inet 130.79.183.186 netmask 0xfc00 broadcast 130.79.183.255 media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g status: associated ssid osiris-sec channel 11 (2462 MHz 11g) bssid 00:26:99:23:69:23 regdomain 106 indoor ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpower 20 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL bintval 102 Ok, so it's in 11bg mode. I'd have to do some digging to try and understand what's busted. CAn you please do this: sysctl dev.ath.0.sample_stats=1 then look at dmesg; it'll dump the sample rate statistics out there. Also, please create a PR for this. I'd like to squish any obvious bugs here before I commit any new stuff. :) Adrian ___ 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: ath0: lot of bad series hwrate and AH_SUPPORT_AR5416
2010/12/1 Adrian Chadd adr...@freebsd.org: On 1 December 2010 18:11, David Demelier demelier.da...@gmail.com wrote: Or is this somehow running in 11A mode? Would you please paste 'ifconfig wlan0' here? mark...@melon ~ $ ifconfig wlan0 wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether c4:17:fe:c4:14:b9 inet 130.79.183.186 netmask 0xfc00 broadcast 130.79.183.255 media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g status: associated ssid osiris-sec channel 11 (2462 MHz 11g) bssid 00:26:99:23:69:23 regdomain 106 indoor ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpower 20 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL bintval 102 Ok, so it's in 11bg mode. I'd have to do some digging to try and understand what's busted. CAn you please do this: sysctl dev.ath.0.sample_stats=1 Oww, mark...@melon ~ $ sudo sysctl dev.ath.0.sample_stats=1 dev.ath.0.sample_stats: 0 - 0 then look at dmesg; it'll dump the sample rate statistics out there. Also, please create a PR for this. I'd like to squish any obvious bugs here before I commit any new stuff. :) Adrian -- Demelier David ___ 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: ath0: lot of bad series hwrate and AH_SUPPORT_AR5416
2010/12/1 David DEMELIER demelier.da...@gmail.com: 2010/12/1 Adrian Chadd adr...@freebsd.org: On 1 December 2010 18:11, David Demelier demelier.da...@gmail.com wrote: Or is this somehow running in 11A mode? Would you please paste 'ifconfig wlan0' here? mark...@melon ~ $ ifconfig wlan0 wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether c4:17:fe:c4:14:b9 inet 130.79.183.186 netmask 0xfc00 broadcast 130.79.183.255 media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g status: associated ssid osiris-sec channel 11 (2462 MHz 11g) bssid 00:26:99:23:69:23 regdomain 106 indoor ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpower 20 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL bintval 102 Ok, so it's in 11bg mode. I'd have to do some digging to try and understand what's busted. CAn you please do this: sysctl dev.ath.0.sample_stats=1 Oww, mark...@melon ~ $ sudo sysctl dev.ath.0.sample_stats=1 dev.ath.0.sample_stats: 0 - 0 [00:26:99:23:69:23] refcnt 4 static_rix -1 ratemask 0xfc8 [ 250] cur rix 10 since switch: packets 79 ticks 6548703 [ 250] last sample 7 cur sample -1 packets sent 390165 [ 250] packets since sample 3 sample tt 524 [1600] cur rix 10 since switch: packets 4 ticks 6532752 [1600] last sample 11 cur sample -1 packets sent 802 [1600] packets since sample 10 sample tt 644 [11: 250]1:1(100%) T1 F0 avg 1103 last 458798 [12: 250] 720:719 ( 99%) T 791 F0 avg 728 last 2022 [12:1600]1:0( 0%) T5 F1 avg 1480 last 458798 [18: 250] 4381:4381 (100%) T 4785 F0 avg 634 last 379 [24: 250]16630:16627( 99%) T18102 F0 avg 622 last 891 [24:1600] 14:11 ( 78%) T 30 F1 avg 1125 last 238025 [36: 250]90373:90368( 99%) T98250 F0 avg 514 last 877 [36:1600] 125:120 ( 96%) T 168 F0 avg 973 last 32568 [48: 250] 117104:117092 ( 99%) T 128546 F0 avg 590 last 362 [48:1600] 198:186 ( 93%) T 280 F0 avg 690 last 16211 [54: 250] 160999:160989 ( 99%) T 176303 F0 avg 529 last 820 [54:1600] 495:485 ( 97%) T 609 F0 avg 986 last 20730 ath0: bad series3 hwrate 0x1b, tries 2 ts_status 0x1 Ah I didn't see there was output. then look at dmesg; it'll dump the sample rate statistics out there. Also, please create a PR for this. I'd like to squish any obvious bugs here before I commit any new stuff. :) Adrian -- Demelier David -- Demelier David ___ 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: ath0: lot of bad series hwrate and AH_SUPPORT_AR5416
Ok; please dump that into a PR and email me the PR number. I'll go see whether there's something simple that can be done - eg, whether that ratemask actually allows the rate being TX'ed and if it doesn't, why the heck it's happening. :-) Adrian On 1 December 2010 19:16, David DEMELIER demelier.da...@gmail.com wrote: 2010/12/1 David DEMELIER demelier.da...@gmail.com: 2010/12/1 Adrian Chadd adr...@freebsd.org: On 1 December 2010 18:11, David Demelier demelier.da...@gmail.com wrote: Or is this somehow running in 11A mode? Would you please paste 'ifconfig wlan0' here? mark...@melon ~ $ ifconfig wlan0 wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether c4:17:fe:c4:14:b9 inet 130.79.183.186 netmask 0xfc00 broadcast 130.79.183.255 media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g status: associated ssid osiris-sec channel 11 (2462 MHz 11g) bssid 00:26:99:23:69:23 regdomain 106 indoor ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpower 20 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL bintval 102 Ok, so it's in 11bg mode. I'd have to do some digging to try and understand what's busted. CAn you please do this: sysctl dev.ath.0.sample_stats=1 Oww, mark...@melon ~ $ sudo sysctl dev.ath.0.sample_stats=1 dev.ath.0.sample_stats: 0 - 0 [00:26:99:23:69:23] refcnt 4 static_rix -1 ratemask 0xfc8 [ 250] cur rix 10 since switch: packets 79 ticks 6548703 [ 250] last sample 7 cur sample -1 packets sent 390165 [ 250] packets since sample 3 sample tt 524 [1600] cur rix 10 since switch: packets 4 ticks 6532752 [1600] last sample 11 cur sample -1 packets sent 802 [1600] packets since sample 10 sample tt 644 [11: 250] 1:1 (100%) T 1 F 0 avg 1103 last 458798 [12: 250] 720:719 ( 99%) T 791 F 0 avg 728 last 2022 [12:1600] 1:0 ( 0%) T 5 F 1 avg 1480 last 458798 [18: 250] 4381:4381 (100%) T 4785 F 0 avg 634 last 379 [24: 250] 16630:16627 ( 99%) T 18102 F 0 avg 622 last 891 [24:1600] 14:11 ( 78%) T 30 F 1 avg 1125 last 238025 [36: 250] 90373:90368 ( 99%) T 98250 F 0 avg 514 last 877 [36:1600] 125:120 ( 96%) T 168 F 0 avg 973 last 32568 [48: 250] 117104:117092 ( 99%) T 128546 F 0 avg 590 last 362 [48:1600] 198:186 ( 93%) T 280 F 0 avg 690 last 16211 [54: 250] 160999:160989 ( 99%) T 176303 F 0 avg 529 last 820 [54:1600] 495:485 ( 97%) T 609 F 0 avg 986 last 20730 ath0: bad series3 hwrate 0x1b, tries 2 ts_status 0x1 Ah I didn't see there was output. then look at dmesg; it'll dump the sample rate statistics out there. Also, please create a PR for this. I'd like to squish any obvious bugs here before I commit any new stuff. :) Adrian -- Demelier David -- Demelier David ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-10:10.openssl
On Mon 2010-11-29 (21:19), FreeBSD Security Advisories wrote:
# cd /usr/src
# patch /path/to/patch
# cd /usr/src/secure/lib/libssl
# make obj make depend make make install
Hi all, I'm following the instructions with:
# cvsup /etc/cvsup-src.conf
# rm -rf /usr/obj
# cd /usr/src/secure/lib/libssl
# make obj make depend make
[ snip ]
cc -O -pipe -DTERMIOS -DANSI_SOURCE
-I/usr/src/secure/lib/libssl/../../../crypto/openssl
-I/usr/src/secure/lib/libssl/../../../crypto/openssl/crypto
-I/usr/obj/usr/src/secure/lib/libssl -DOPENSSL_THREADS -DDSO_DLFCN
-DHAVE_DLFCN_H -DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu99
-fstack-protector -c
/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/d1_both.c
/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/d1_both.c: In function
'dtls1_hm_fragment_new':
/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/d1_both.c:210: error:
'hm_fragment' has no member named 'reassembly'
[ more hm_fragment.reassembly errors .. ]
*** Error code 1
Stop in /usr/src/secure/lib/libssl.
What's going on?
hm_fragment is (only) defined in /usr/src/crypto/openssl/ssl/dtls1.h:
typedef struct hm_fragment_st
{
struct hm_header_st msg_header;
unsigned char *fragment;
unsigned char *reassembly;
} hm_fragment;
which has that member and is sourced from the Makefiles.
The first existence complaint in d1_both.c is:
frag-reassembly = bitmask;
yet
frag-fragment = buf;
a few lines earlier is fine?
___
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
IPv6 + CARP + VLANs + pf == panic on 8-stable
[ Pardon the cross-post, feel free to follow up to just one list, I'm on both. ] Running a system on the latest 8-stable as a router we are seeing the following panic: http://pastebin.com/AJzXmEWe Kernel is as follows: include GENERIC ident ROUTER options SW_WATCHDOG options DEVICE_POLLING options TCP_SIGNATURE options IPSEC device crypto device cryptodev device carp device pf device pflog device pfsync options ALTQ options ALTQ_CBQ# Class Bases Queuing (CBQ) options ALTQ_RED# Random Early Detection (RED) options ALTQ_RIO# RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_PRIQ # Priority Queuing (PRIQ) options ALTQ_NOPCC # Required for SMP build options WITNESS options INVARIANTS options INVARIANT_SUPPORT options DDB options BREAK_TO_DEBUGGER Advice and suggestions welcome. A quick look at the diff between HEAD and RELENG_8 didn't show anything obvious to me in the areas affected, but that doesn't mean it isn't there. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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
Re: 8.1-RELEASE: snd_hda works as module only, suspend/resume leaves display off
2010/11/15 Stefan Walter ste...@freebsd.org: Hi, I've been using 8.1-RELEASE on this desktop machine for a few months already, but only now found the time to look at a couple of problems with snd_hda and suspend/resume it still has. Maybe someone here has hints to fix them - I'd be grateful to hear them. Audio with snd_hda(4) works, but only if loaded as a module AND only if I load the module AFTER booting. If I compile it into the kernel or add snd_hda_load=YES to /boot/loader.conf, dmesg shows the following: hdac0: HDA Codec #0: ATI RS690/780 HDMI pcm0: HDA ATI RS690/780 HDMI PCM #0 HDMI at cad 0 nid 1 on hdac0 hdac1: HDA Codec #0: Realtek ALC885 pcm1: HDA Realtek ALC885 PCM #0 Analog at cad 0 nid 1 on hdac1 pcm2: HDA Realtek ALC885 PCM #1 Analog at cad 0 nid 1 on hdac1 pcm3: HDA Realtek ALC885 PCM #2 Digital at cad 0 nid 1 on hdac1 mixer(8) shows: Mixer vol is currently set to 75:75 Mixer pcm is currently set to 75:75 There is no audio in that case. Unloading and reloading the module (or just loading the module manually after the boot process) logs: hdac0: ATI SB600 High Definition Audio Controller mem 0xfe024000-0xfe027fff irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC885 hdac1: ATI (Unknown) High Definition Audio Controller mem 0xfdffc000-0xfdff irq 19 at device 5.1 on pci1 hdac1: HDA Driver Revision: 20100226_0142 hdac1: [ITHREAD] hdac1: HDA Codec #0: ATI RS690/780 HDMI pcm0: HDA Realtek ALC885 PCM #0 Analog at cad 0 nid 1 on hdac0 pcm1: HDA Realtek ALC885 PCM #1 Analog at cad 0 nid 1 on hdac0 pcm2: HDA Realtek ALC885 PCM #2 Digital at cad 0 nid 1 on hdac0 pcm3: HDA ATI RS690/780 HDMI PCM #0 HDMI at cad 0 nid 1 on hdac1 mixer then shows: Mixer vol is currently set to 75:75 Mixer pcm is currently set to 75:75 Mixer speaker is currently set to 75:75 Mixer line is currently set to 75:75 Mixer mic is currently set to 0:0 Mixer mix is currently set to 0:0 Mixer rec is currently set to 75:75 Mixer igain is currently set to 0:0 Audio then seems to work fine. (Plugging earphones into the computer's case's front plugs doesn't do anything, though - audio still comes from the speakers attached to the plug at the back of the case. Any ideas about that?) Loading snd_hda from a startup script would probably work, but I guess that's not the way it was meant to work. The other problem is with suspend/resume: Suspend To RAM (S3) works by using acpiconf -s 3, and pushing the power button wakes the system up again. Everything seems to work, only the LCD monitor remains off. (There also seem to be occasional cases in which the keyboard doesn't work any more, but I haven't really looked at that, yet. Usually, the system comes back up properly.) Loading dpms(4) doesn't seem to make a difference. The only way to turn the display on again seems to be typing shutdown -r now blindly. Regards, Stefan Same here, if I have snd_hda directly in kernel, screen doesn't wake up with or without hw.acpi.reset_video=1. I don't like much modules since it takes some time to load at boot so if a fix could be made it will be great.. Cheers, -- Demelier David ___ 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
pcm says `channel dead' with snd_hda
~ uname -a FreeBSD compaq.yuetime 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #8: Thu Nov 25 15:48:19 CST 2010 r...@compaq.yuetime:/usr/obj/usr/src/sys/HOUKAGO amd64 Sometimes, pcm prints the following message to the console dmesg. pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead What's wrong? I haven't seen this in 8.1-RELEASE or other version before. One post said that such message comes with noise, but I'm not sure. I uses mplayer, sometimes quodlibet (gstreamer backend). -- Zhihao Yuan The best way to predict the future is to invent it. ___ 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: 8.1-RELEASE: snd_hda works as module only, suspend/resume leaves display off
On Wed, Dec 1, 2010 at 3:49 PM, David DEMELIER demelier.da...@gmail.comwrote: Same here, if I have snd_hda directly in kernel, screen doesn't wake up with or without hw.acpi.reset_video=1. I don't like much modules since it takes some time to load at boot Are you booting from a tape drive or something? -- Adam Vande More ___ 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: 8.1-RELEASE: snd_hda works as module only, suspend/resume leaves display off
2010/12/1 Adam Vande More amvandem...@gmail.com: On Wed, Dec 1, 2010 at 3:49 PM, David DEMELIER demelier.da...@gmail.com wrote: Same here, if I have snd_hda directly in kernel, screen doesn't wake up with or without hw.acpi.reset_video=1. I don't like much modules since it takes some time to load at boot Are you booting from a tape drive or something? -- Adam Vande More No, but loading if you convert your kernel into modules, it takes a lot of time to load every modules. PC-BSD does it and it's slow. -- Demelier David ___ 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: 8.1-RELEASE: snd_hda works as module only, suspend/resume leaves display off
I have exactly the same problem, the video never wakes up for acpiconf -s 3. My computer is HP nc8430, with 8.2-PRELEASE amd64. My old laptop Dell Inspiron 1100 with FreeBSD5.5 i386 has the same problem. So FreeBSD just can't handle suspend on my laptops :) On Wed, Dec 1, 2010 at 3:49 PM, David DEMELIER demelier.da...@gmail.comwrote: 2010/11/15 Stefan Walter ste...@freebsd.org: Hi, I've been using 8.1-RELEASE on this desktop machine for a few months already, but only now found the time to look at a couple of problems with snd_hda and suspend/resume it still has. Maybe someone here has hints to fix them - I'd be grateful to hear them. Audio with snd_hda(4) works, but only if loaded as a module AND only if I load the module AFTER booting. If I compile it into the kernel or add snd_hda_load=YES to /boot/loader.conf, dmesg shows the following: hdac0: HDA Codec #0: ATI RS690/780 HDMI pcm0: HDA ATI RS690/780 HDMI PCM #0 HDMI at cad 0 nid 1 on hdac0 hdac1: HDA Codec #0: Realtek ALC885 pcm1: HDA Realtek ALC885 PCM #0 Analog at cad 0 nid 1 on hdac1 pcm2: HDA Realtek ALC885 PCM #1 Analog at cad 0 nid 1 on hdac1 pcm3: HDA Realtek ALC885 PCM #2 Digital at cad 0 nid 1 on hdac1 mixer(8) shows: Mixer vol is currently set to 75:75 Mixer pcm is currently set to 75:75 There is no audio in that case. Unloading and reloading the module (or just loading the module manually after the boot process) logs: hdac0: ATI SB600 High Definition Audio Controller mem 0xfe024000-0xfe027fff irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC885 hdac1: ATI (Unknown) High Definition Audio Controller mem 0xfdffc000-0xfdff irq 19 at device 5.1 on pci1 hdac1: HDA Driver Revision: 20100226_0142 hdac1: [ITHREAD] hdac1: HDA Codec #0: ATI RS690/780 HDMI pcm0: HDA Realtek ALC885 PCM #0 Analog at cad 0 nid 1 on hdac0 pcm1: HDA Realtek ALC885 PCM #1 Analog at cad 0 nid 1 on hdac0 pcm2: HDA Realtek ALC885 PCM #2 Digital at cad 0 nid 1 on hdac0 pcm3: HDA ATI RS690/780 HDMI PCM #0 HDMI at cad 0 nid 1 on hdac1 mixer then shows: Mixer vol is currently set to 75:75 Mixer pcm is currently set to 75:75 Mixer speaker is currently set to 75:75 Mixer line is currently set to 75:75 Mixer mic is currently set to 0:0 Mixer mix is currently set to 0:0 Mixer rec is currently set to 75:75 Mixer igainis currently set to 0:0 Audio then seems to work fine. (Plugging earphones into the computer's case's front plugs doesn't do anything, though - audio still comes from the speakers attached to the plug at the back of the case. Any ideas about that?) Loading snd_hda from a startup script would probably work, but I guess that's not the way it was meant to work. The other problem is with suspend/resume: Suspend To RAM (S3) works by using acpiconf -s 3, and pushing the power button wakes the system up again. Everything seems to work, only the LCD monitor remains off. (There also seem to be occasional cases in which the keyboard doesn't work any more, but I haven't really looked at that, yet. Usually, the system comes back up properly.) Loading dpms(4) doesn't seem to make a difference. The only way to turn the display on again seems to be typing shutdown -r now blindly. Regards, Stefan Same here, if I have snd_hda directly in kernel, screen doesn't wake up with or without hw.acpi.reset_video=1. I don't like much modules since it takes some time to load at boot so if a fix could be made it will be great.. Cheers, -- Demelier David ___ 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 -- Zhihao Yuan The best way to predict the future is to invent it. ___ 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: Fwd: Re: Fail to use Dtrace on FreeBSD 8.1-STABLE
OK. Let's make this more clear: anyone has a working 8-2-PRERELEASE kernel
(amd64 is preferred) with Dtrace supports, which can run the
scripts/commands on the wiki? If so, please post your kernel configurations
here, thanks.
On Tue, Nov 23, 2010 at 7:27 AM, Andriy Gapon a...@freebsd.org wrote:
on 23/11/2010 15:25 Jeremy Chadwick said the following:
On Tue, Nov 23, 2010 at 05:13:53AM -0800, Jeremy Chadwick wrote:
On Tue, Nov 23, 2010 at 02:39:47PM +0200, Andriy Gapon wrote:
on 23/11/2010 10:20 Zhihao Yuan said the following:
Attach my kernel configuration here, just in case.
On 00:12 Tue 23 Nov, Jeremy Chadwick wrote:
Forwarding back to the mailing list since the OP didn't CC it on his
reply to me.
- Forwarded message from Zhihao Yuan lich...@gmail.com -
From: Zhihao Yuan lich...@gmail.com
To: Jeremy Chadwick free...@jdc.parodius.com
Date: Tue, 23 Nov 2010 01:18:57 -0600
Subject: Re: Fail to use Dtrace on FreeBSD 8.1-STABLE
I followed the instructions, but still can not run any D-scripts.
All
scripts shows the error message that I just posted.
Are the installed world and the installed kernel in sync?
(Built from the same state of source code).
The same question.
FWIW, I can reproduce his problem when following the procedure outlined
in the Wiki.
As a workaround I tried adding WITH_CTF=true to /etc/src.conf and
rebuilding + reinstalling world + reboot, to no avail. I'm rebuilding
the kernel now to see if that makes a difference after the above
workaround.
Nope, no go.
icarus# kldload dtraceall
icarus# dtrace -lP syscall
dtrace: invalid probe specifier syscall: /usr/lib/dtrace/psinfo.d, line
37: syntax error near uid_t
icarus# ls -l /boot/kernel/kernel
-r-xr-xr-x 1 root wheel 7180261 Nov 23 05:16 /boot/kernel/kernel
icarus# ls -l /usr/lib/dtrace
total 32
-r--r--r-- 1 root wheel 8608 Nov 23 05:09 drti.o
-r--r--r-- 1 root wheel 6910 Nov 23 05:09 errno.d
-r--r--r-- 1 root wheel 3196 Nov 23 05:09 psinfo.d
-r--r--r-- 1 root wheel 3597 Nov 23 05:09 regs_x86.d
-r--r--r-- 1 root wheel 3121 Nov 23 05:09 signal.d
-r--r--r-- 1 root wheel 2019 Nov 23 05:09 unistd.d
icarus# vim /usr/lib/dtrace/psinfo.d
...
31 typedef struct psinfo {
32 int pr_nlwp;/* number of threads */
33 pid_t pr_pid; /* unique process id */
34 pid_t pr_ppid;/* process id of parent */
35 pid_t pr_pgid;/* pid of process group leader */
36 pid_t pr_sid; /* session id */
37 uid_t pr_uid; /* real user id */
38 uid_t pr_euid;/* effective user id */
39 gid_t pr_gid; /* real group id */
40 gid_t pr_egid;/* effective group id */
--
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
--
Zhihao Yuan
The best way to predict the future is to invent it.
___
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: Stale NFS file handles on 8.x amd64
I'll give negnametimeo=0 a try on one server starting tonight, I'll be busy tomorrow and don't want to risk making anything potentially worse than it is yet. I can't figure out how to disable the attr cache in FreeBSD. Neither suggestions seem to be valid, and years ago when I looked into it I got the impression that you can't, but I'd love to be proven wrong. I just looked and, yea, you are correct, in that the cached attributes are still used while NMODIFIED is set if the mtime isn't within the current second. (I'm not going to veture a guess as to why this is done at this time:-) But, acregmon=0,acregmax=0,acdirmin=0,acdirmax=0 looks like it comes close, from a quick inspection of the code. I haven't tested this. You do have to set both min and max == 0, or max just gets set to min instead of 0. The *dir* ones apply to directories and the *reg* ones otherwise. I'll try dotlock when I can. Would disabling statd and lockd be the same as using nolock on all mounts? Nope. If you kill off lockd and statd without using the nolock option, I think all file lock operations will fail with ENOTSUPPORTED whereas when you mount with nolock, the lock ops will be done locally in the client (ie seen by other processes in the same client, but not by other clients). The vacation binary is the only thing I can think of that might use it, not sure how well it would like missing it which is how I discovered I needed it in the first place. Also, if disabling lockd shows an improvement, could it lead to further investigation or is it just a workaround? Well, it's a work around in the sense that you are avoiding the NLM and NSM protocols. These are fundamentally flawed protocol designs imho, but some folks find that they work ok for them. Imho, the two big flaws are: 1 - Allowing a blocking lock in the server. Then what happens if the client is network partitioned when the server finally acquires the lock for the client? (NFSv4 only allows the server to block for a very short time before it replies. The client must poll until the lock is available, if the client app. allows blocking. In other works, the client does the blocking.) 2 - It depends upon the NSM to decide if a node is up/down. I'm not sure what the NSM actually does, but it's along the lines of an IP broadcast to see if the other host(s) are responding and then sets up/down based on how recently it saw a message from a given host. (NFSv4 requires that the server recognize a lock request where the client had state that predates this boot and reply with an error that tells the client to recover its lock state using special variants of the lock ops. Imho, this does a much better job of making sure the server and clients maintain a consistent set of lock state. The server may throw away lock state for an NFSv4 client if it hasn't renewed the state within a lease time and then the client will be given an expired error to tell it that it has lost locks. This should only happen when a network partitioning exceeds the lease duration and, in the case of the FreeBSD NFSv4 server, it has also received a conflicting lock request from another client whose lease has not expired.) Probably a lot more glop than you expected, but I couldn't resist a chance to put in a plug for NFSv4 file locking. Btw, you could try NFSv4 mounts, since Netapp and the experimental FreeBSD8 client both support them. Good lock (oh, I meant luck:-) with it, rick ___ 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: Fwd: Re: Fail to use Dtrace on FreeBSD 8.1-STABLE
On Wed, Dec 1, 2010 at 4:30 PM, Zhihao Yuan lich...@gmail.com wrote: OK. Let's make this more clear: anyone has a working 8-2-PRERELEASE kernel (amd64 is preferred) with Dtrace supports, which can run the scripts/commands on the wiki? If so, please post your kernel configurations here, thanks. I have an i386 system working: FreeBSD d820.flick.local 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #2 r216091: Wed Dec 1 18:06:20 CST 2010 r...@d820.flick.local:/usr/obj/usr/src/sys/D820 i386 Just built the kernel and ran through some tests on the DTrace wiki page. Incidentally, I had a tough time on my system running HEAD built with clang. DTrace simply would not run properly until I built the kernel with the base gcc. It was as if the kernel and userland were not in sync, no matter what I tried (even netstat didn't work). Maybe you need to clean EVERYTHING, checkout a clean source tree (if you've been mucking around in there), and rebuild and install kernel and world. I wish I could help more, but I'm still just a newb in a lot of respects... -Brandon ___ 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: Fwd: Re: Fail to use Dtrace on FreeBSD 8.1-STABLE
On Wed, Dec 01, 2010 at 06:22:40PM -0600, Brandon Gooch wrote: On Wed, Dec 1, 2010 at 4:30 PM, Zhihao Yuan lich...@gmail.com wrote: OK. Let's make this more clear: anyone has a working 8-2-PRERELEASE kernel (amd64 is preferred) with Dtrace supports, which can run the scripts/commands on the wiki? If so, please post your kernel configurations here, thanks. I have an i386 system working: [snip] Can you please try the command the OP originally provided? See command here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-November/060216.html -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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
Uh, fxp driver broken in current -STABLE build?!
Works in this kernel, checked out on that day: FreeBSD 8.1-STABLE #10: Mon Aug 30 06:44:40 CDT 2010 k...@fs.denninger.net:/usr/obj/usr/src/sys/KSD-SMP fxp0: Intel 82558 Pro/100 Ethernet port 0x1000-0x101f mem 0x9400-0x94000fff,0x9410-0x941f irq 21 at device 0.0 on pci6 fxp0: Enabling Rx lock-up workaround miibus0: MII bus on fxp0 fxp0: Ethernet address: 00:a0:c9:a4:78:c3 fxp0: [ITHREAD] (and has been running for months, and for a very long time before that) Tried to update to today's check-out and got hosed. The driver now keeps resetting and sending out down and up messages repeatedly, and no traffic flows This is the ident I have on the current build: fxp0: Intel 82558 Pro/100 Ethernet port 0x1000-0x101f mem 0x9400-0x94000fff,0x9410-0x941f irq 21 at device 0.0 on pci6 fxp0: Enabling Rx lock-up workaround miibus0: MII bus on fxp0 fxp0: Ethernet address: 00:a0:c9:a4:78:c3 fxp0: [ITHREAD] Looks the same. Something was touched though on Nov 30 in the CVS tree. It looks like there was a fairly serious commit posted on 10-15, and some other smaller ones related to VLANs and flow control (which don't apply to this configuration.) I can't find anything else related.. anyone know what's up here? Probably need to find this as we're going into the 8.2 RELEASE cycle. DMESG from the failed kernel boot is attached. -- Karl Denninger Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-PRERELEASE #12: Wed Dec 1 13:03:01 CST 2010 k...@fs.denninger.net:/usr/obj/usr/src/sys/KSD-SMP i386 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU @ 2.40GHz (2409.70-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6f7 Family = 6 Model = f Stepping = 7 Features=0xbfebfbffFPU,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=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2010NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2084683776 (1988 MB) ACPI APIC Table: INTEL D975XBX2 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 2 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: INTEL D975XBX2 on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 acpi_button0: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 vgapci0: VGA-compatible display mem 0x9300-0x93ff,0x8000-0x8fff,0x9200-0x92ff irq 16 at device 0.0 on pci1 pcib2: PCI-PCI bridge at device 3.0 on pci0 pci2: PCI bus on pcib2 pcib3: PCI-PCI bridge at device 0.0 on pci2 pci3: PCI bus on pcib3 puc0: Oxford Semiconductor OX16PCI954 UARTs port 0x4060-0x407f,0x4040-0x405f mem 0x94503000-0x94503fff,0x94502000-0x94502fff irq 16 at device 0.0 on pci3 puc0: [FILTER] uart2: 16550 or compatible on puc0 uart2: [FILTER] uart3: 16550 or compatible on puc0 uart3: [FILTER] uart4: 16550 or compatible on puc0 uart4: [FILTER] uart5: 16550 or compatible on puc0 uart5: [FILTER] pci3: bridge at device 0.1 (no driver attached) hdac0: Intel 82801G High Definition Audio Controller mem 0x9460-0x94603fff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] pcib4: ACPI PCI-PCI bridge at device 28.0 on pci0 pci4: ACPI PCI bus on pcib4 3ware device driver for 9000 series storage controllers, version: 3.80.06.003 twa0: 3ware 9000 series Storage Controller port 0x3000-0x30ff mem 0x9000-0x91ff,0x9440-0x94400fff irq 16 at device 0.0 on pci4 twa0: [ITHREAD] twa0: INFO: (0x15: 0x1300): Controller details:: Model 9650SE-8LPML, 8 ports, Firmware FE9X 4.08.00.006, BIOS BE9X 4.08.00.001 pcib5: ACPI PCI-PCI bridge at device 28.5 on pci0 pci5: ACPI PCI bus on pcib5 em0: Intel(R) PRO/1000 Network Connection 7.1.8 port 0x2000-0x201f mem 0x9430-0x9431 irq 17 at device 0.0 on pci5 em0: Using an MSI interrupt em0: [FILTER] em0: Ethernet address: 00:19:d1:e3:b4:b8 uhci0: Intel 82801G (ICH7) USB controller USB-A port 0x5080-0x509f irq 23 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: Intel 82801G (ICH7) USB controller USB-A on uhci0 uhci1: Intel 82801G (ICH7) USB controller USB-B port 0x5060-0x507f irq 19 at
Re: Fwd: Re: Fail to use Dtrace on FreeBSD 8.1-STABLE
On Wed, Dec 1, 2010 at 6:27 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: On Wed, Dec 01, 2010 at 06:22:40PM -0600, Brandon Gooch wrote: On Wed, Dec 1, 2010 at 4:30 PM, Zhihao Yuan lich...@gmail.com wrote: OK. Let's make this more clear: anyone has a working 8-2-PRERELEASE kernel (amd64 is preferred) with Dtrace supports, which can run the scripts/commands on the wiki? If so, please post your kernel configurations here, thanks. I have an i386 system working: [snip] Can you please try the command the OP originally provided? See command here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-November/060216.html d820# dtrace -lP syscall | head ID PROVIDERMODULE FUNCTION NAME 17syscall syscall entry 18syscall syscall return 19syscallexit entry 20syscallexit return 21syscallfork entry 22syscallfork return 23syscallread entry 24syscallread return 25syscall write entry The error the OP received from the above command was pretty much exactly what I was seeing when I attempting to use DTrace on my HEAD system, built with clang. Same error, at least this part: /usr/lib/dtrace/psinfo.d, line 88: failed to resolve type kernel`struct thread * for identifier curthread: Unknown type name I was running simply 'dtrace -l' to list all probes... -Brandon ___ 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: Uh, fxp driver broken in current -STABLE build?!
On Wed, Dec 01, 2010 at 06:11:11PM -0600, Karl Denninger wrote:
Works in this kernel, checked out on that day:
FreeBSD 8.1-STABLE #10: Mon Aug 30 06:44:40 CDT 2010
k...@fs.denninger.net:/usr/obj/usr/src/sys/KSD-SMP
fxp0: Intel 82558 Pro/100 Ethernet port 0x1000-0x101f mem
0x9400-0x94000fff,0x9410-0x941f irq 21 at device 0.0 on pci6
fxp0: Enabling Rx lock-up workaround
miibus0: MII bus on fxp0
fxp0: Ethernet address: 00:a0:c9:a4:78:c3
fxp0: [ITHREAD]
(and has been running for months, and for a very long time before that)
Tried to update to today's check-out and got hosed.
The driver now keeps resetting and sending out down and up messages
repeatedly, and no traffic flows
This is the ident I have on the current build:
fxp0: Intel 82558 Pro/100 Ethernet port 0x1000-0x101f mem
0x9400-0x94000fff,0x9410-0x941f irq 21 at device 0.0 on pci6
fxp0: Enabling Rx lock-up workaround
miibus0: MII bus on fxp0
fxp0: Ethernet address: 00:a0:c9:a4:78:c3
fxp0: [ITHREAD]
Looks the same.
Something was touched though on Nov 30 in the CVS tree.
It looks like there was a fairly serious commit posted on 10-15, and
some other smaller ones related to VLANs and flow control (which don't
apply to this configuration.)
I can't find anything else related.. anyone know what's up here?
Probably need to find this as we're going into the 8.2 RELEASE cycle.
DMESG from the failed kernel boot is attached.
Thanks for reporting. Try attached patch. It seems there is a bug
in RX lockup detection logic. Your controller is known to RX
lockup free so the workaround should not be enabled. Otherwise
fxp(4) reinitializes the controller every 15 seconds.
Index: sys/dev/fxp/if_fxp.c
===
--- sys/dev/fxp/if_fxp.c (revision 216097)
+++ sys/dev/fxp/if_fxp.c (working copy)
@@ -526,10 +526,12 @@
}
/* Receiver lock-up workaround detection. */
- fxp_read_eeprom(sc, data, 3, 1);
- if ((data 0x03) != 0x03) {
- sc-flags |= FXP_FLAG_RXBUG;
- device_printf(dev, Enabling Rx lock-up workaround\n);
+ if (sc-revision FXP_REV_82558_A4) {
+ fxp_read_eeprom(sc, data, 3, 1);
+ if ((data 0x03) != 0x03) {
+ sc-flags |= FXP_FLAG_RXBUG;
+ device_printf(dev, Enabling Rx lock-up workaround\n);
+ }
}
/*
___
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: Fwd: Re: Fail to use Dtrace on FreeBSD 8.1-STABLE
I guess such an error has nothing to do with the difference between compilers... I assumed that you used similar KERNCONF on your two systems. So, a hypothesis is: Dtrace does not work correctly on amd64. On Wed, Dec 1, 2010 at 6:37 PM, Brandon Gooch jamesbrandongo...@gmail.comwrote: On Wed, Dec 1, 2010 at 6:27 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: On Wed, Dec 01, 2010 at 06:22:40PM -0600, Brandon Gooch wrote: On Wed, Dec 1, 2010 at 4:30 PM, Zhihao Yuan lich...@gmail.com wrote: OK. Let's make this more clear: anyone has a working 8-2-PRERELEASE kernel (amd64 is preferred) with Dtrace supports, which can run the scripts/commands on the wiki? If so, please post your kernel configurations here, thanks. I have an i386 system working: [snip] Can you please try the command the OP originally provided? See command here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-November/060216.html d820# dtrace -lP syscall | head ID PROVIDERMODULE FUNCTION NAME 17syscall syscall entry 18syscall syscall return 19syscallexit entry 20syscallexit return 21syscallfork entry 22syscallfork return 23syscallread entry 24syscallread return 25syscall write entry The error the OP received from the above command was pretty much exactly what I was seeing when I attempting to use DTrace on my HEAD system, built with clang. Same error, at least this part: /usr/lib/dtrace/psinfo.d, line 88: failed to resolve type kernel`struct thread * for identifier curthread: Unknown type name I was running simply 'dtrace -l' to list all probes... -Brandon -- Zhihao Yuan The best way to predict the future is to invent it. ___ 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: Uh, fxp driver broken in current -STABLE build?!
On 12/1/2010 6:44 PM, Pyun YongHyeon wrote: On Wed, Dec 01, 2010 at 06:11:11PM -0600, Karl Denninger wrote: Works in this kernel, checked out on that day: FreeBSD 8.1-STABLE #10: Mon Aug 30 06:44:40 CDT 2010 k...@fs.denninger.net:/usr/obj/usr/src/sys/KSD-SMP fxp0: Intel 82558 Pro/100 Ethernet port 0x1000-0x101f mem 0x9400-0x94000fff,0x9410-0x941f irq 21 at device 0.0 on pci6 fxp0: Enabling Rx lock-up workaround miibus0: MII bus on fxp0 fxp0: Ethernet address: 00:a0:c9:a4:78:c3 fxp0: [ITHREAD] (and has been running for months, and for a very long time before that) Tried to update to today's check-out and got hosed. The driver now keeps resetting and sending out down and up messages repeatedly, and no traffic flows This is the ident I have on the current build: fxp0: Intel 82558 Pro/100 Ethernet port 0x1000-0x101f mem 0x9400-0x94000fff,0x9410-0x941f irq 21 at device 0.0 on pci6 fxp0: Enabling Rx lock-up workaround miibus0: MII bus on fxp0 fxp0: Ethernet address: 00:a0:c9:a4:78:c3 fxp0: [ITHREAD] Looks the same. Something was touched though on Nov 30 in the CVS tree. It looks like there was a fairly serious commit posted on 10-15, and some other smaller ones related to VLANs and flow control (which don't apply to this configuration.) I can't find anything else related.. anyone know what's up here? Probably need to find this as we're going into the 8.2 RELEASE cycle. DMESG from the failed kernel boot is attached. Thanks for reporting. Try attached patch. It seems there is a bug in RX lockup detection logic. Your controller is known to RX lockup free so the workaround should not be enabled. Otherwise fxp(4) reinitializes the controller every 15 seconds. ___ 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 The patch was successful. I have another problem with the new kernel in that it is not properly blocking on reads from an attached GPS (NTPD) but I'll see what I can find out there and update as necessary. This probably needs to be committed so it doesn't bite other people. -- Karl ___ 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: Fwd: Re: Fail to use Dtrace on FreeBSD 8.1-STABLE
On Wed, Dec 1, 2010 at 7:37 PM, Zhihao Yuan lich...@gmail.com wrote: I guess such an error has nothing to do with the difference between compilers... I assumed that you used similar KERNCONF on your two systems. So, a hypothesis is: Dtrace does not work correctly on amd64. I should have mentioned that I do have DTrace sort of working on my HEAD system (amd64), just strange terminal behavior now (CTRL-C doesn't allow a running script to produce any output -- pkill dtrace works however...). I just found this, which seems to indicate that you may be on to something: http://forums.freebsd.org/showthread.php?t=19028 What does your kernel config look like? How about /etc/make.conf and /etc/src.conf? Maybe looking at the contents of these files will shed some light... -Brandon ___ 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: Fwd: Re: Fail to use Dtrace on FreeBSD 8.1-STABLE
On Wed, Dec 1, 2010 at 5:37 PM, Zhihao Yuan lich...@gmail.com wrote: I guess such an error has nothing to do with the difference between compilers... I assumed that you used similar KERNCONF on your two systems. So, a hypothesis is: Dtrace does not work correctly on amd64. It works just fine for me. I built my amd64 kernel a week or so back with this KERNCONF: include GENERIC ident DWARF options KDTRACE_FRAME options KDTRACE_HOOKS options KDB options DDB options DDB_CTF Can you check with ctfdump if you objects actually have CTF information in them? Something like this: # ctfdump -S /boot/kernel/kernel # ctfdump /boot/kernel/kernel | grep ... Regards, Navdeep On Wed, Dec 1, 2010 at 6:37 PM, Brandon Gooch jamesbrandongo...@gmail.comwrote: On Wed, Dec 1, 2010 at 6:27 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: On Wed, Dec 01, 2010 at 06:22:40PM -0600, Brandon Gooch wrote: On Wed, Dec 1, 2010 at 4:30 PM, Zhihao Yuan lich...@gmail.com wrote: OK. Let's make this more clear: anyone has a working 8-2-PRERELEASE kernel (amd64 is preferred) with Dtrace supports, which can run the scripts/commands on the wiki? If so, please post your kernel configurations here, thanks. I have an i386 system working: [snip] Can you please try the command the OP originally provided? See command here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-November/060216.html d820# dtrace -lP syscall | head ID PROVIDER MODULE FUNCTION NAME 17 syscall syscall entry 18 syscall syscall return 19 syscall exit entry 20 syscall exit return 21 syscall fork entry 22 syscall fork return 23 syscall read entry 24 syscall read return 25 syscall write entry The error the OP received from the above command was pretty much exactly what I was seeing when I attempting to use DTrace on my HEAD system, built with clang. Same error, at least this part: /usr/lib/dtrace/psinfo.d, line 88: failed to resolve type kernel`struct thread * for identifier curthread: Unknown type name I was running simply 'dtrace -l' to list all probes... -Brandon -- Zhihao Yuan The best way to predict the future is to invent it. ___ 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 ___ 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: Fwd: Re: Fail to use Dtrace on FreeBSD 8.1-STABLE
ctfdump -S /boot/kernel/kernel works, my system has CTF configured. But I don't have either options KDB or options DDB I guess these has nothing to do with Dtrace, at least KDB is just a totally different module. Am I right? On Wed, Dec 1, 2010 at 7:47 PM, Navdeep Parhar npar...@gmail.com wrote: On Wed, Dec 1, 2010 at 5:37 PM, Zhihao Yuan lich...@gmail.com wrote: I guess such an error has nothing to do with the difference between compilers... I assumed that you used similar KERNCONF on your two systems. So, a hypothesis is: Dtrace does not work correctly on amd64. It works just fine for me. I built my amd64 kernel a week or so back with this KERNCONF: include GENERIC ident DWARF options KDTRACE_FRAME options KDTRACE_HOOKS options KDB options DDB options DDB_CTF Can you check with ctfdump if you objects actually have CTF information in them? Something like this: # ctfdump -S /boot/kernel/kernel # ctfdump /boot/kernel/kernel | grep ... Regards, Navdeep On Wed, Dec 1, 2010 at 6:37 PM, Brandon Gooch jamesbrandongo...@gmail.comwrote: On Wed, Dec 1, 2010 at 6:27 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: On Wed, Dec 01, 2010 at 06:22:40PM -0600, Brandon Gooch wrote: On Wed, Dec 1, 2010 at 4:30 PM, Zhihao Yuan lich...@gmail.com wrote: OK. Let's make this more clear: anyone has a working 8-2-PRERELEASE kernel (amd64 is preferred) with Dtrace supports, which can run the scripts/commands on the wiki? If so, please post your kernel configurations here, thanks. I have an i386 system working: [snip] Can you please try the command the OP originally provided? See command here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-November/060216.html d820# dtrace -lP syscall | head ID PROVIDERMODULE FUNCTION NAME 17syscall syscall entry 18syscall syscall return 19syscallexit entry 20syscallexit return 21syscallfork entry 22syscallfork return 23syscallread entry 24syscallread return 25syscall write entry The error the OP received from the above command was pretty much exactly what I was seeing when I attempting to use DTrace on my HEAD system, built with clang. Same error, at least this part: /usr/lib/dtrace/psinfo.d, line 88: failed to resolve type kernel`struct thread * for identifier curthread: Unknown type name I was running simply 'dtrace -l' to list all probes... -Brandon -- Zhihao Yuan The best way to predict the future is to invent it. ___ 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 -- Zhihao Yuan The best way to predict the future is to invent it. ___ 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: Fwd: Re: Fail to use Dtrace on FreeBSD 8.1-STABLE
On Wed, Dec 01, 2010 at 08:21:21PM -0600, Zhihao Yuan wrote: ctfdump -S /boot/kernel/kernel works, my system has CTF configured. But I don't have either options KDB or options DDB I guess these has nothing to do with Dtrace, at least KDB is just a totally different module. Am I right? Correct; KDB/DDB shouldn't have anything to do with this. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-10:10.openssl
On 12/01/2010 12:53, Gareth de Vaux wrote:
On Mon 2010-11-29 (21:19), FreeBSD Security Advisories wrote:
# cd /usr/src
# patch /path/to/patch
# cd /usr/src/secure/lib/libssl
# make obj make depend make make install
Hi all, I'm following the instructions with:
# cvsup /etc/cvsup-src.conf
# rm -rf /usr/obj
# cd /usr/src/secure/lib/libssl
# make obj make depend make
[ snip ]
cc -O -pipe -DTERMIOS -DANSI_SOURCE
-I/usr/src/secure/lib/libssl/../../../crypto/openssl
-I/usr/src/secure/lib/libssl/../../../crypto/openssl/crypto
-I/usr/obj/usr/src/secure/lib/libssl -DOPENSSL_THREADS -DDSO_DLFCN
-DHAVE_DLFCN_H -DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu99
-fstack-protector -c
/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/d1_both.c
/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/d1_both.c: In function
'dtls1_hm_fragment_new':
/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/d1_both.c:210: error:
'hm_fragment' has no member named 'reassembly'
[ more hm_fragment.reassembly errors .. ]
*** Error code 1
Stop in /usr/src/secure/lib/libssl.
What's going on?
hm_fragment is (only) defined in /usr/src/crypto/openssl/ssl/dtls1.h:
typedef struct hm_fragment_st
{
struct hm_header_st msg_header;
unsigned char *fragment;
unsigned char *reassembly;
} hm_fragment;
which has that member and is sourced from the Makefiles.
The first existence complaint in d1_both.c is:
frag-reassembly = bitmask;
yet
frag-fragment = buf;
a few lines earlier is fine?
___
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
Try that with a ( make includes ) in that same directory and if it works
then the advisory will have to be revised.
so it should be
make obj
make depend
make includes
make make install
If all else fails a buildworld would work for you...
Regards,
--
jhell,v
___
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
