if_wpi is all kinds of broken
The if_wpi driver is all kinds of broken. The reported problems really just are the tip of the iceberg: http://www.freebsd.org/cgi/query-pr.cgi?pr=144898 A notebook without wireless is really just a portable workstation. I've seen a lot of commits to other wireless drivers in recent months. So it's not like nobody's working on this kind of stuff. Because no amount of persuasion and detailed bug reports help and I have no clue what the error codes returned by the firmware blob imply (documentation anywhere?), I think I have to ask the one question: Where do I have to put my cash to make somebody fix this? ___ 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: if_wpi is all kinds of broken
On 01/-10/63 19:59, Dominic Fandrey wrote: The if_wpi driver is all kinds of broken. The reported problems I have had trouble with all Intel drivers, ipw, iwi, wpi, and iwn. (As an exception, recently, iwn was very stable on 8-STABLE.) For most notebooks, I bought Atheros based MiniPCI(e) cards and everything was fine. Where do I have to put my cash to make somebody fix this? 5 to 10 Euros on Ebay including shipping. Initially, I was hesitant, too, because I wanted the hardware I already got to work, but eventually I decided that it is not worse it. ath simply works. (I have had wi, ral, ural, rum, and zyd, too. Over the years, nothing was as unproblematic as ath.) For most notebooks, the wireless MiniPCI(e) card is very easy to replace. Cheers, Jan Henrik ___ 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: if_wpi is all kinds of broken
On Mon, May 17, 2010 at 4:01 PM, Jan Henrik Sylvester wrote: > On 01/-10/63 19:59, Dominic Fandrey wrote: >> >> The if_wpi driver is all kinds of broken. The reported problems > > I have had trouble with all Intel drivers, ipw, iwi, wpi, and iwn. (As an > exception, recently, iwn was very stable on 8-STABLE.) For most notebooks, I > bought Atheros based MiniPCI(e) cards and everything was fine. > >> Where do I have to put my cash to make somebody fix this? > > 5 to 10 Euros on Ebay including shipping. Initially, I was hesitant, too, > because I wanted the hardware I already got to work, but eventually I > decided that it is not worse it. ath simply works. (I have had wi, ral, > ural, rum, and zyd, too. Over the years, nothing was as unproblematic as > ath.) > > For most notebooks, the wireless MiniPCI(e) card is very easy to replace. > > Cheers, > Jan Henrik Note that not all laptops will play nicely with different wifi cards. My old HP laptop would not boot up past the BIOS if you replaced the wifi card with one not in its magic list, which I found out after I had bought an ath based mini pci-e card to replace it (which is still spare if anyone wants it). 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: if_wpi is all kinds of broken
On 17/05/2010 15:44, Tom Evans wrote: > On Mon, May 17, 2010 at 4:01 PM, Jan Henrik Sylvester wrote: >> On 01/-10/63 19:59, Dominic Fandrey wrote: >>> >>> The if_wpi driver is all kinds of broken. The reported problems >> >> I have had trouble with all Intel drivers, ipw, iwi, wpi, and iwn. (As an >> exception, recently, iwn was very stable on 8-STABLE.) For most notebooks, I >> bought Atheros based MiniPCI(e) cards and everything was fine. >> >>> Where do I have to put my cash to make somebody fix this? >> >> 5 to 10 Euros on Ebay including shipping. Initially, I was hesitant, too, >> because I wanted the hardware I already got to work, but eventually I >> decided that it is not worse it. ath simply works. (I have had wi, ral, >> ural, rum, and zyd, too. Over the years, nothing was as unproblematic as >> ath.) >> >> For most notebooks, the wireless MiniPCI(e) card is very easy to replace. > > Note that not all laptops will play nicely with different wifi cards. > My old HP laptop would not boot up past the BIOS if you replaced the > wifi card with one not in its magic list, which I found out after I > had bought an ath based mini pci-e card to replace it (which is still > spare if anyone wants it). Thanks for that information. I know that the if_wpi driver does some stuff with the bluetooth hardware (I think the bluetooth hardware is part of the wpi hardware) and the BIOS allows some pretty dedicated settings. It really might all blow up if I exchange the hardware. I'll have to give it a try, though. I think I still have an old ipw lying around somewhere (from a broken Thinkpad), if this works I might consider buying ath. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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"
Release Cycle for 8.1-RELEASE...
Just FYI, we are about a week away from starting code freeze for the 8.1-RELEASE release cycle. Since sometimes that means stable/8 gets a little less reliable due to higher than normal levels of developer activity I'll adjust the branch to say it is 8.1-PRERELEASE now. The target schedule for the release cycle is available here: http://www.freebsd.org/releases/8.1R/schedule.html And the wiki page to track the current status of the release (started but not heavily used yet) is here: http://wiki.freebsd.org/Releng/8.1TODO The current target release date is July 9th, 2010. Thanks. -- Ken Smith - From there to here, from here to | kensm...@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
Re: if_wpi is all kinds of broken
On Mon, 17 May 2010, Dominic Fandrey wrote: On 17/05/2010 15:44, Tom Evans wrote: Note that not all laptops will play nicely with different wifi cards. My old HP laptop would not boot up past the BIOS if you replaced the wifi card with one not in its magic list, which I found out after I had bought an ath based mini pci-e card to replace it (which is still spare if anyone wants it). Thanks for that information. I know that the if_wpi driver does some stuff with the bluetooth hardware (I think the bluetooth hardware is part of the wpi hardware) and the BIOS allows some pretty dedicated settings. It really might all blow up if I exchange the hardware. I'll have to give it a try, though. I think I still have an old ipw lying around somewhere (from a broken Thinkpad), if this works I might consider buying ath. The ipw card in my T42 is the older mini-PCI (no "e"). ipw has some driver problems (kern/142766), but Bernhard Schmidt is working on it and has it somewhat functional now. -Warren Block * Rapid City, South Dakota USA ___ 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"
Problem, install Freebsd 8 in Adaptec 29320A, not recognizes raid
Hi. I'm trying to install FreeBSD on a server that eighth in which I have a adaptec 29320A controller with two 36 GB Seagate drives in raid 0. When I go to install the freebsd it detects only disks and not the raid. ___ 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: Crash dump problem - sleeping thread owns a non-sleepable lock during crash dump write
On Friday 14 May 2010 11:42:44 am Matthew Fleming wrote:
> > As an aside, this is a quad-core in one package CPU (an X3363). On both
> > this box and a similar one with an X5470, console messages continue to
> > print out after "the system has been halted - press any key to reboot" -
> > in particular, the shutdown makes a bunch of the "behind the scenes" man-
> > agement stuff like the virtual keyboard and monitor appear. Plugging or
> > unplugging USB devices will go through the whole deal of detecting and
> > making their service available.
>
> Oops, youre right that other CPUs are running.
>
> The stop_cpus() call is only made if kdb is entered. doadump() is called
out of boot() which comes later. At Isilon weve been running with a patch
that does stop_cpus() pretty close to the front of panic(9).
>
> As an design decision it seems reasonable to call stop_cpus() early in
panic(9) simply because most causes for panic means something unexpected, and
the sooner the other CPUs arent running the more likely it is that they dont
do more damage, leaving the system in a more useful state for dump or {g,d}db
analysis. This should be done before dump or entering kdb.
>
> Im ccing -current@ since I would like a small discussion of moving the
stop_cpus() to earlier in panic. If this change is agreeable I can roll up a
patch and test it on CURRENT. Im not sure yet how much of the other panic-
related changes we have made at Isilon would be required.
Right now what happens on x86 is that cpu_reset() actually ends up stopping
the other CPUs. It's good that cpu_reset() does this so that 'reset' from DDB
works. That said, it would probably be a good thing to stop CPUs earlier
during a panic, and even during a normal shutdown. One issue with using
stop_cpus() during shutdown is that it is too severe of a stop. That is,
stop_cpus() doesn't release the threads currently running. This could be a
problem during a normal shutdown if a non-boot CPU is running an interrupt
thread needed during shutdown, etc. I think what we really want is a way to
take CPUs offline (which Attilio is working on) and use that during a normal
shutdown. A quick fix might be a way to force CPUs offline where you have a
'shutdown' or 'offline' mask of sorts and teach the scheduler to only return
the idlethread in that case and then send an IPI_PREEMPT to all the CPUs.
That will break any pinned or bound threads pinned to non-boot CPUs though.
--
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: Crash dump problem - sleeping thread owns a non-sleepable lock during crash dump write
On Friday 14 May 2010 7:59:40 am Terry Kennedy wrote: > > > The crash was a "page fault while in kernel mode" with the current process > > > being the interrupt service routine for the bce0 GigE. Things progressed > > > reasonably until partway through the dump, when the system locked up with > > > a > > > "Sleeping thread (tid 100028, pid 12) owns a non-sleepable lock". That's > > > the > > > same PID as reported in the main crash. > > > > Hmm. You could try changing the code to not do a nested panic in that > > case. You would update subr_turnstile.c to just return if panicstr is > > not NULL rather than calling panic. However, there is still a good > > chance you will end up deadlocking in that case. I have another patch I > > can send you next week that prevents blocking on mutexes duing a panic > > which may also help. > > Ok, I'll be glad to try that. --- //depot/vendor/freebsd/src/sys/kern/kern_mutex.c2010/01/23 15:55:14 +++ //depot/projects/smpng/sys/kern/kern_mutex.c2010/03/10 22:33:24 @@ -348,6 +348,15 @@ return; } + /* +* If we have already panic'd and this is the thread that called +* panic(), then don't block on any mutexes but silently succeed. +* Otherwise, the kernel will deadlock since the scheduler isn't +* going to run the thread that holds the lock we need. +*/ + if (panicstr != NULL && curthread->td_flags & TDF_INPANIC) + return; + lock_profile_obtain_lock_failed(&m->lock_object, &contested, &waittime); if (LOCK_LOG_TEST(&m->lock_object, opts)) @@ -664,6 +673,15 @@ } /* +* If we failed to unlock this lock and we are a thread that has +* called panic(), it may be due to the bypass in _mtx_lock_sleep() +* above. In that case, just return and leave the lock alone to +* avoid changing the state. +*/ + if (panicstr != NULL && curthread->td_flags & TDF_INPANIC) + return; + + /* * We have to lock the chain before the turnstile so this turnstile * can be removed from the hash list if it is empty. */ > > > 3) Is there any way to rig the system to obtain more info if this happens > > > again? Right now I'm using an embedded remote console server, but I could > > > switch the system to a serial port if enabling the kernel debugger might > > > help. > > > But I think that the sleeping thread bit would happen even at the debugger > > > prompt, wouldn't it? > > > > Include DDB and enable the 'trace_on_panic' sysctl knob perhaps. > > Hmmm. Do you think it will get very far before the sleeping thread business > locks it up? It should be able to print the backtrace when it panics at least. -- 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"
odd behavior on select() after shutdown()
Hi all,
Select(2) has three arguments to get socket status for read, write and except.
After upgrading to 8.0-RELEASE, select() after shutdown(SHUT_WR) returns with
the status exceptfds is set. It means out-of-bound data can be read
from the socket,
but recv() with OOB flag returns ECONNRESET, and no packets with urgent flag
was observed by tcpdump.
It seems strange for me, but is it an intentional change on 8.x ?
This behavior breaks net/stone on 8.0-RELEASE.
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/141103
The continuous recv() error on PR might lead by incorrectly setted
exceptfds on every recv()
and it should be fixed, but it doesn't matter if above behavior of
select() doesn't occur.
You can reproduce this by following example:
#include
#include
#include
#include
#include
#include
int main() {
int ret;
int s;
s = socket(PF_INET, SOCK_STREAM, 0);
struct sockaddr_in sa;
sa.sin_family = AF_INET;
sa.sin_addr.s_addr = inet_addr("127.0.0.1");
sa.sin_port = htons(22);
ret = connect(s, (struct sockaddr*)&sa, sizeof(sa));
if (ret) perror("connect");
/* get OpenSSH greetings */
char buf[BUFSIZ];
memset(buf, 0, sizeof(buf) / sizeof(buf[0]));
ret = recv(s, buf, sizeof(buf), 0);
if (ret < 0) perror("recv");
printf("recv: %s\n", buf);
/* send something incorrect */
printf("send: \\r\\n\n");
ret = send(s, "\r\n", 2, 0);
if (ret < 0) perror("send");
/* receive "Protocol mismatch" */
memset(buf, 0, sizeof(buf) / sizeof(buf[0]));
ret = recv(s, buf, sizeof(buf), 0);
if (ret < 0) perror("recv");
printf("recv: %s\n", buf);
/* shutdown */
ret = shutdown(s, SHUT_WR); /* SHUT_RD doesn't make problem. */
if (ret) perror("shutdown");
/* select */
fd_set readfds, exceptfds;
FD_ZERO(&readfds);
FD_ZERO(&exceptfds);
FD_SET(s, &readfds);
FD_SET(s, &exceptfds);
ret = select(s+1, &readfds, NULL, &exceptfds, NULL);
if (ret < 1) perror("select");
printf("select: read:%d except:%d\n",
FD_ISSET(s, &readfds), FD_ISSET(s, &exceptfds));
if (FD_ISSET(s, &exceptfds)) {
printf("read OOB data\n");
memset(buf, 0, sizeof(buf) / sizeof(buf[0]));
ret = recv(s, buf, sizeof(buf), MSG_OOB);
if (ret < 0) perror("recv");
printf("recv(OOB): %s\n", buf);
}
FD_ZERO(&readfds);
FD_SET(s, &readfds);
ret = select(s+1, &readfds, NULL, NULL, NULL);
if (ret < 1) perror("select");
printf("select: read:%d\n", FD_ISSET(s, &readfds));
memset(buf, 0, sizeof(buf) / sizeof(buf[0]));
ret = recv(s, buf, sizeof(buf), 0);
if (ret < 0) perror("recv");
printf("recv: %s\n", buf);
close(s);
}
Thanks in advance
- Yoshihiko
___
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: Problem with ath(4) RELENG_8
On 17/05/2010 04:14, Guillermo Amaral wrote: > On Mon, May 10, 2010 at 8:38 PM, Guillermo Amaral wrote: > >> I have been using RELENG_8 for a while and some time ago the wireless driver >> started acting funny, by this I mean that for example in RELENG_8_0 the ath >> driver radio switch works, I can connect AND stay connected with out a hitch. >> >> In RELENG_8 it has progressively gone from good to bad to worse, at first the >> radio on/off switch stopped working (it did change color but the driver never >> really turned off the radio), then any wifi I connected to stopped responding >> after about 5 minutes, I then need to restart wlan0 for it to reconnect >> and give me 5 more minutes, now the wifi radio switch won't even change >> color. >> >> I thought maybe this was something temporary but just in case it's not and >> nobody knows that this is going on I decided to send this mail. >> > Anybody know where I can send this to? I'm thinking this was not the > right mailing-list then. :S > > I've recently submitted a pr (kern/146517) about problems with an AR5B91 (same chip id) so its been registered there is an issue but feel free to try -net if you like as it may not be the same. Vince ___ 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: odd behavior on select() after shutdown()
On Tue, May 18, 2010 at 01:08:50AM +0900, Yoshihiko Sarumaru wrote:
> Hi all,
>
> Select(2) has three arguments to get socket status for read, write and except.
> After upgrading to 8.0-RELEASE, select() after shutdown(SHUT_WR) returns with
> the status exceptfds is set. It means out-of-bound data can be read
> from the socket,
> but recv() with OOB flag returns ECONNRESET, and no packets with urgent flag
> was observed by tcpdump.
> It seems strange for me, but is it an intentional change on 8.x ?
>
> This behavior breaks net/stone on 8.0-RELEASE.
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/141103
> The continuous recv() error on PR might lead by incorrectly setted
> exceptfds on every recv()
> and it should be fixed, but it doesn't matter if above behavior of
> select() doesn't occur.
The patch below would fix the problem at hand. I am wondering what
unintended consequences it might have.
diff --git a/sys/kern/sys_generic.c b/sys/kern/sys_generic.c
index eaefd9c..293dbb1 100644
--- a/sys/kern/sys_generic.c
+++ b/sys/kern/sys_generic.c
@@ -996,7 +996,7 @@ done:
static int select_flags[3] = {
POLLRDNORM | POLLHUP | POLLERR,
POLLWRNORM | POLLHUP | POLLERR,
-POLLRDBAND | POLLHUP | POLLERR
+POLLRDBAND | POLLERR
};
/*
pgprmQLycSGvs.pgp
Description: PGP signature
Re: if_wpi is all kinds of broken
Hi, On 17 May 2010 17:05, Warren Block wrote: > On Mon, 17 May 2010, Dominic Fandrey wrote: >>[...] > The ipw card in my T42 is the older mini-PCI (no "e"). Yes, and replacing this card is a problem, because the wireless card in many IBM Thinkpad Laptops have a custom firmware, and the cards ID is listed in the laptops BIOS. It won't work with any card not listed there. There are ways to either flash the cards firmware or the BIOS list, but I don't think that it's worth it. Regards Christian Walther ___ 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: if_wpi is all kinds of broken
> Date: Mon, 17 May 2010 21:26:42 +0200 > From: Christian Walther > Sender: owner-freebsd-sta...@freebsd.org > > Hi, > > On 17 May 2010 17:05, Warren Block wrote: > > On Mon, 17 May 2010, Dominic Fandrey wrote: > >>[...] > > > The ipw card in my T42 is the older mini-PCI (no "e"). > > Yes, and replacing this card is a problem, because the wireless card > in many IBM Thinkpad Laptops have a custom firmware, and the cards ID > is listed in the laptops BIOS. It won't work with any card not listed > there. There are ways to either flash the cards firmware or the BIOS > list, but I don't think that it's worth it. Assuming the the Atheros you are installing is one that IBM/Lenovo used, it will work fine. The 5212 in the mini-PCI format was sold by IBM for the t-40, T-42, and T-43 laptops and works fine. Other cards will probably not work in the T-42. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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"
Give freeze a chance
The next wave of the challenge, fear, there is one more already composed to be released with 8.1! -- Give Freeze a chance with apologies to John Lennon et al Ev'rybody's talkin' 'bout portism, srcism, docism, cvsism, svnism, tagism This-ism, that-ism, ism ism ism All we are saying is give freeze a chance All we are saying is give freeze a chance C'mon Ev'rybody's talkin' 'bout re@, core@, doceng@, donations@, secteam@, marketing@, portmgr@, vendor-relations@ All we are saying is give freeze a chance All we are saying is give freeze a chance Let me tell you now Ev'rybody's talkin' 'bout Revolution, evolution, i18n, l10n, documentation, Integration, administration, applications, congratulations All we are saying is give freeze a chance All we are saying is give freeze a chance Ev'rybody's talkin' 'bout Erwin Lansing, Mark Linimon, Martin Wilke, Pav Lucistnik, Florent Thoumie, Ion-Mihai Tetcu, Kris Kennaway, Joe Marcus Clarke, Thomas Abthorpe too All we are saying is give freeze a chance All we are saying is give freeze a chance Thomas -- Thomas Abthorpe | FreeBSD Committer tabtho...@freebsd.org | http://people.freebsd.org/~tabthorpe pgpggnrJ067p0.pgp Description: PGP signature
Re: if_wpi is all kinds of broken
On Mon, 17 May 2010, Christian Walther wrote: Hi, On 17 May 2010 17:05, Warren Block wrote: On Mon, 17 May 2010, Dominic Fandrey wrote: [...] The ipw card in my T42 is the older mini-PCI (no "e"). Yes, and replacing this card is a problem, because the wireless card in many IBM Thinkpad Laptops have a custom firmware, and the cards ID is listed in the laptops BIOS. It won't work with any card not listed there. There are ways to either flash the cards firmware or the BIOS list, but I don't think that it's worth it. Just because I have this link handy: http://www.paul.sladen.org/thinkpad-r31/wifi-card-pci-ids.html That also has a link to some information on HP's version of the same thing. -Warren Block * Rapid City, South Dakota USA ___ 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: if_wpi is all kinds of broken
On 17/05/2010 23:29, Warren Block wrote: > On Mon, 17 May 2010, Christian Walther wrote: > >> Hi, >> >> On 17 May 2010 17:05, Warren Block wrote: >>> On Mon, 17 May 2010, Dominic Fandrey wrote: [...] >> >>> The ipw card in my T42 is the older mini-PCI (no "e"). >> >> Yes, and replacing this card is a problem, because the wireless card >> in many IBM Thinkpad Laptops have a custom firmware, and the cards ID >> is listed in the laptops BIOS. It won't work with any card not listed >> there. There are ways to either flash the cards firmware or the BIOS >> list, but I don't think that it's worth it. > > Just because I have this link handy: > http://www.paul.sladen.org/thinkpad-r31/wifi-card-pci-ids.html > > That also has a link to some information on HP's version of the same thing. The official genuine parts list for my notebook only lists Intel and Boradcom wireless modules. So I suppose I'll just have to risk buying a PCIe Atheros that I cannot use. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: odd behavior on select() after shutdown()
Hi, 2010/5/18 Kostik Belousov : > On Tue, May 18, 2010 at 01:08:50AM +0900, Yoshihiko Sarumaru wrote: >> Hi all, >> >> Select(2) has three arguments to get socket status for read, write and >> except. >> After upgrading to 8.0-RELEASE, select() after shutdown(SHUT_WR) returns with >> the status exceptfds is set. It means out-of-bound data can be read >> from the socket, >> but recv() with OOB flag returns ECONNRESET, and no packets with urgent flag >> was observed by tcpdump. >> It seems strange for me, but is it an intentional change on 8.x ? > The patch below would fix the problem at hand. I am wondering what > unintended consequences it might have. It works perfect for me on 8.0-RELEASE, thanks! I can't see how much this change has side effects, but is it commitable to current or stable? Kib, it seems you had changed some code using POLLHUP in uipc_socket.c. I'm not sure it is related to this issue, but could you give us your comments? thanks, - yoshihiko ___ 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"
[releng_8 tinderbox] failure on amd64/amd64
TB --- 2010-05-18 04:31:50 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-05-18 04:31:50 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2010-05-18 04:31:50 - cleaning the object tree TB --- 2010-05-18 04:32:16 - cvsupping the source tree TB --- 2010-05-18 04:32:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/amd64/amd64/supfile TB --- 2010-05-18 04:33:28 - building world TB --- 2010-05-18 04:33:28 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-18 04:33:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-18 04:33:28 - TARGET=amd64 TB --- 2010-05-18 04:33:28 - TARGET_ARCH=amd64 TB --- 2010-05-18 04:33:28 - TZ=UTC TB --- 2010-05-18 04:33:28 - __MAKE_CONF=/dev/null TB --- 2010-05-18 04:33:28 - cd /src TB --- 2010-05-18 04:33:28 - /usr/bin/make -B buildworld >>> World build started on Tue May 18 04:33:29 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -std=gnu99 -fstack-protector -c /src/lib/libusbhid/data.c /src/lib/libusbhid/data.c: In function 'hid_get_data': /src/lib/libusbhid/data.c:63: error: 'int32_t' undeclared (first use in this function) /src/lib/libusbhid/data.c:63: error: (Each undeclared identifier is reported only once /src/lib/libusbhid/data.c:63: error: for each function it appears in.) /src/lib/libusbhid/data.c:63: error: expected ')' before 'data' /src/lib/libusbhid/data.c:65: error: 'uint32_t' undeclared (first use in this function) /src/lib/libusbhid/data.c:65: error: expected ')' before 'data' *** Error code 1 Stop in /src/lib/libusbhid. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-05-18 05:01:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-05-18 05:01:30 - ERROR: failed to build world TB --- 2010-05-18 05:01:30 - 1237.80 user 268.95 system 1780.05 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full ___ 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"
