Re: When you get a moment.
I have a VAIO with an AC97 soundcard. Here's the pciconf output: pcm0@pci0:31:5: class=0x040100 card=0x80fa104d chip=0x24858086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801CA/CAM (ICH3-S/ICH3-M) AC'97 Audio Controller' class= multimedia subclass = audio Here's the /var/log/messages entry: Nov 26 18:53:34 islir /kernel: pcm0: port 0x18c0-0x18ff,0x1c00-0x1cff irq 9 at device 31.5 on pci0 Now it works fine, but only if I constantly wiggle my USB mouse. If I take a look at /var/log/messages, all the USB controllers share the same IRQ (9). Of course, this all works fine under Windows XP with the IRQs all the same. I've looked into the BIOS and there is hardly anything you can set and certainly no settings for PnP or PCI. Any suggestions? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Broken IPv6 DNS servers (Was: Is gethostbyname2() reentrant?)
Yeah. I'm in the middle of the Mozilla code base as you probably remember, trying to fix the problem of these bad DNS servers. I did complain to the technical administrators for the ones that were giving me problems, but I've only received form letter replies and they are still broken. I also saw the recent sendmail thread on the same issue. It just isn't acceptable to users to have a 90 second wait for these broken DNS servers. I really wish we could come up with some fix below the application level. Mozilla was already using the apartment model for operating systems that do not have a reentrant gethostbyname2(). I did make a patch for Mozilla that lets it do async dns on systems that have a reentrant gethostbyname2(), but obviously that doesn't help on FreeBSD. Perhaps we can come up with some acceptable change to the gethostbyname2() implementation that will deal with these broken DNS servers without causing problems for the end users or violating the 'correct' behaviour. How about this change to the gethostbyname2() implementation. First it fires off an request and if it doesn't get a reply in 5 seconds, then fire off an A request to the same server. If it gets a reply to the A request, it writes a message to syslog complaining about a broken DNS server. If it doesn't get a reply to the A request, it can just do the standard timeout thing. This should give you correct results in the case the DNS server is really broken and speed up the results in the case where the DNS server just suffers from this bug. Admittedly, you could have a problem where the reply has been sent but lost or delayed for more than 5 seconds, but that seems like a lesser problem than making the user wait 90 seconds or failing to deliver email. We could make this algorithm dependent on a sysctl variable that is off by default, but you could turn it on if you are having lots of problems with IPv6 lookups. Any other suggestions? Please don't tell me to complain to the owner of the DNS servers. I have done that. If you feel that is the proper solution, please complain yourself to [EMAIL PROTECTED] who is the Technical Contact for vanguard's domain. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is gethostbyname2() reentrant?
>On May 31, Peter Haight wrote: >> >> If I link with libc_r can I use gethostbyname2() at the same time in two >> different threads? > >Pardon my ignorance, but how does re-entrancy affect this? It would seem >that you're interested in a function that doesn't block. The function returns a pointer to some sort of memory. I'm worried that the the two separate requests could possibly mess up each others memory. Maybe I have the terminology wrong. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyname2 and AF_INET6
>You would do everyone a favour by notifying those sites that don't >handle IPv6 DNS queries properly. In many (most) cases the sites aren't >aware that their DNS software is broken. A quick e-mail will often see >the problem fixed in short order. (bbc.co.uk is a recent example of >this.) Of course. What's a good thing to tell them? Is the problem that their DNS server isn't correctly responding to a query with an unknown QTYPE? The main reason I want to have Mozilla work around this is that for many people, they are not interested in policing DNS servers. They just want Mozilla to work. Yes, those DNS servers are broken and should be fixed, but Mozilla should work nicely in either case. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyname2 and AF_INET6
>In mozilla's case, it's not the FreeBSD resolver that's trying ipv6 and >then ipv4. Mozilla does it explicitly by calling gethostbyname2 first >with AF_INET6, and if that fails with AF_INET. You could just patch it >to not make the first gethostbyname2 call. From a quick browse of the >source from mozilla.org it's src/misc/prnetdb.c around line # 579 or >thereabouts. Yeah. That's exactly what I did to make it work nicely on my machine, but that's not a real solution as it breaks IPv6 resolving. I'm going to try Terry's solution and try and do concurrent lookups. Mozilla is already using pthreads, so I should be able to just spawn the two requests in separate threads and take the one that comes back first. I may even spawn the IPv6 one a little earlier to give it a slightly better chance of coming back first. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyname2 and AF_INET6
>www.vanguard.com has a broken DNS implementation. >Find out the zone administrator via SOA record or whois and complain. >RFC requires the behavour you saw with google. Ok. The thing is that there are a lot of these sites. Watching the log on the other side of my DNS server it looks like it is sending requests to vanguard's dns server, but not getting any replies. Is there some way I can lower the timeout for IPV6 DNS lookups or maybe disable them? Or is there some change I can make to mozilla to minimize the impact of sites like these? Hmm. Looking at the FreeBSD resolver code, it doesn't look like there is some convenient way to do this. Maybe something like, try the lookup, but if we don't get any reply in a short timeout, try an A lookup. If we get a reply to that, then log the site as probably not conforming to the RFC. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
gethostbyname2 and AF_INET6
Recently mozilla has been really slow resolving some DNS queries. I tracked
this down to a call to gethostbyname2. For some addresses (e.g.
'www.vanguard.com'), gethostbyname2 with AF_INET6 will fail and takes more
than a minute. I verified this with my own short program that does nothing
but call gethostbyname2.
I've attached a tcpdump of two DNS lookups. One is against
'www.vanguard.com' which takes about a minute and thirty seconds to come
back with an 'Host name lookup failure'.
The second log is against 'www.google.com' and it returns almost immediately
with 'No address associated with name'.
Can someone explain to me what's going on?
Thanks.
--- Log of gethostbyname2('www.vanguard.com', AF_INET6) ---
15:43:20.359250 255.128.174.zip > 0.0.zip: at-#6 25
15:43:21.033482 talri.sapros.com.1640 > wartch.sapros.com.domain: 20502+ ?
www.vanguard.com. (34)
15:43:21.358839 talri.sapros.com.1641 > wartch.sapros.com.domain: 42707+ PTR?
1.1.10.10.in-addr.arpa. (40)
15:43:21.359253 wartch.sapros.com.domain > talri.sapros.com.1641: 42707* 1/1/1
PTR[|domain]
15:43:21.359618 talri.sapros.com.1642 > wartch.sapros.com.domain: 42708+ PTR?
9.1.10.10.in-addr.arpa. (40)
15:43:21.359965 wartch.sapros.com.domain > talri.sapros.com.1642: 42708* 1/1/1
PTR[|domain]
15:43:21.408548 255.128.174.zip > 0.0.zip: at-#6 25
15:43:22.458620 255.128.174.zip > 0.0.zip: at-#6 25
15:43:24.258444 0:40:1:80:22:d6 > Broadcast sap e0 ui/C
>>> Unknown IPX Data: (79 bytes)
[000] FF FF 00 60 00 04 00 00 00 00 FF FF FF FF FF FF ...`
[010] 04 52 00 00 00 00 00 40 01 80 22 D6 04 52 00 02 .R.@ .."..R..
[020] 55 AA 5A 4F 54 2D 50 53 38 30 32 32 44 36 00 00 U.ZOT-PS 8022D6..
[030] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[040] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...
len=97
0060 0004
0452 0040 0180 22d6 0452 0002
55aa 5a4f 542d 5053 3830 3232 4436
00
15:43:26.037875 talri.sapros.com.1643 > mxrelay.lanminds.com.domain: 20502+ ?
www.vanguard.com. (34)
15:43:26.358016 talri.sapros.com.1644 > wartch.sapros.com.domain: 42709+ PTR?
6.88.25.208.in-addr.arpa. (42)
15:43:26.358693 wartch.sapros.com.domain > talri.sapros.com.1644: 42709 1/4/4
PTR[|domain]
15:43:26.922809 wartch.sapros.com.11512 > talri.sapros.com.1074: .
1417795364:1417795365(1) ack 1842336180 win 33304
(DF)
15:43:26.922873 talri.sapros.com.1074 > wartch.sapros.com.11512: . ack 0 win 0
(DF)
15:43:31.047974 talri.sapros.com.1645 > ns2.lmi.net.domain: 20502+ ?
www.vanguard.com. (34)
15:43:31.358121 talri.sapros.com.1646 > wartch.sapros.com.domain: 42710+ PTR?
5.64.25.208.in-addr.arpa. (42)
15:43:31.359089 wartch.sapros.com.domain > talri.sapros.com.1646: 42710 1/3/2
PTR[|domain]
15:43:36.058129 talri.sapros.com.1647 > wartch.sapros.com.domain: 20502+ ?
www.vanguard.com. (34)
15:43:37.358336 talri.sapros.com.1648 > wartch.sapros.com.domain: 42711+ PTR?
47.203.186.198.in-addr.arpa. (45)
15:43:37.360077 wartch.sapros.com.domain > talri.sapros.com.1648: 42711 1/3/0 (149)
15:43:39.068217 talri.sapros.com.1649 > mxrelay.lanminds.com.domain: 20502+ ?
www.vanguard.com. (34)
15:43:42.078303 talri.sapros.com.nkd > ns2.lmi.net.domain: 20502+ ?
www.vanguard.com. (34)
15:43:45.088393 talri.sapros.com.shiva_confsrvr > wartch.sapros.com.domain: 20502+
? www.vanguard.com. (34)
15:43:51.098565 talri.sapros.com.xnmp > mxrelay.lanminds.com.domain: 20502+ ?
www.vanguard.com. (34)
15:43:53.163592 wartch.sapros.com.11512 > talri.sapros.com.1074: . 0:1(1) ack 1 win
33304 (DF)
15:43:53.163683 talri.sapros.com.1074 > wartch.sapros.com.11512: . ack 0 win 0
(DF)
15:43:57.108743 talri.sapros.com.1653 > ns2.lmi.net.domain: 20502+ ?
www.vanguard.com. (34)
15:44:03.118926 talri.sapros.com.1654 > wartch.sapros.com.domain: 20502+ ?
www.vanguard.com. (34)
15:44:16.129309 talri.sapros.com.1655 > mxrelay.lanminds.com.domain: 20502+ ?
www.vanguard.com. (34)
15:44:19.404375 wartch.sapros.com.11512 > talri.sapros.com.1074: . 0:1(1) ack 1 win
33304 (DF)
15:44:19.404469 talri.sapros.com.1074 > wartch.sapros.com.11512: . ack 0 win 0
(DF)
15:44:26.016010 255.128.174.zip > 0.0.zip: at-#6 25
15:44:26.765395 0:40:1:80:22:d6 > Broadcast sap e0 ui/C
>>> Unknown IPX Data: (79 bytes)
[000] FF FF 00 60 00 04 00 00 00 00 FF FF FF FF FF FF ...`
[010] 04 52 00 00 00 00 00 40 01 80 22 D6 04 52 00 02 .R.@ .."..R..
[020] 55 AA 5A 4F 54 2D 50 53 38 30 32 32 44 36 00 00 U.ZOT-PS 8022D6..
[030] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[040] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...
len=97
0060 0004
pthread_attr_setschedparam, mozilla, and PTHREAD_MAX_PRIORITY
I rebuilt mozilla after upgrading to 4.2 and was getting an assertion because pthread_attr_setschedparam() was failing with a ENOTSUP. It turns out Mozilla was trying to set the thread priority to 42 which is above the new limit of 31 which changed a little before 4.2-RELEASE. To patch mozilla I had to do a '#if __FreeBSD_version >= 42' because PTHREAD_MAX_PRIORITY is in a private pthreads header file. I'm wondering if it might not be a good idea to have that define show up somewhere public? The only other thing I can think of is to call pthread_attr_setschedparam() a couple of times to scope out the range of accepted values. Or maybe I'm missing some better solution. (I'm not on the list, so please cc me). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
