Re: Sound card troubles
On Sat, 20 Sep 2003, Bruce Mackay wrote: Hey all, I get the following hang up when I try booting up, here's the problem area... pcm0: Intel ICH3 (82801CA) at device 31.5 on pci0 pcm0: unable to map IO port space device_probe_and_attach: pcm0 attach returned 6 I'm running a CVSUP -current from Thu Sep 18 12:34:00 EDT 2003, I have a Yamaha YMF753 Codex Chip and it's Sound Blaster Pro compatible card, anyone have any suggestions? Try setting the tunable hw.pci.allow_unsupported_io_range to 1 in loader.conf and booting. Your machine appears to need special consideration; most ICH3 chips don't need this option. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_sk build fails
On Sat, 20 Sep 2003, Pawel Worach wrote: Hi! Last if_sk update broke buildkernel === sk rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/../include /usr/src/sys/modules/sk/../../pci/if_sk.c /usr/src/sys/pci/if_sk.c:129:26: pci/yukonreg.h: No such file or directory mkdep: compile failed if_sk.c revision? It should be 1.65. This was a problem last week or so... -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
On Sat, Sep 20, 2003 at 07:24:07PM -0700, Kris Kennaway wrote: OK, here's what we can do to fix this: 1) Put back -pthread in -current so all the ports don't fail 2) I will build a full set of -current packages with the -pthread error still in place, to determine the list of packages that need to be fixed (in fact I already have this, see http://dosirak.kr.freebsd.org/errorlogs). 3) You, John Birrell, and whoever else is interested in fixing these ports can work on them at your own pace without disrupting life for the rest of the users. Once they're all fixed, we can turn the error back on or make it a NOP or do whatever else is decided to be appropriate. 4) It is likely that steps 2 and 3 will need to be iterated several times, because there are dozens of ports that need to be fixed, and many of them are hiding other ports that depend on them and also need to be fixed. I don't know if there is much point to #1 at this point since it's been gone for about 2 weeks now. #2/3/4 sounds fine to me. In the meantime KF is working on a patch to properly support PTHREAD_LIBS in KDE's configure scripts. We plan to commit it when the freeze lifts, pending PR #55325. I suggest that people not build ports on -CURRENT for a few weeks until things get sorted out, unless they're going to fix the problems with specific ports. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
recursive lock problem.
Running a recent current, I got a recursive lock panic with the lock first acquired in net80211/ieee80211_node.c:525 and reacquired in 547. The machine in question uses the following wi0 in hostap mode: wi0: Intersil Prism2.5 mem 0xcecff000-0xcecf irq 11 at device 17.0 on pci0 wi0: 802.11 address: 00:05:5d:ee:e6:e7 wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) wi0: Intersil Firmware: Primary (1.0.5), Station (1.3.4) wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps With the following ifconfig line: ifconfig_wi0=inet 192.168.192.1/24 media autoselect mode 11b mediaopt hostap ssid f00dbar channel 11 Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The bikeshed T-shirt
In message: [EMAIL PROTECTED] Daniel Eischen [EMAIL PROTECTED] writes: : Can you add a no -pthread symbol to it? Can you give it a rest? You made a bad call, people are giving you grief for it. That is not a bikeshed. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
On Sat, 20 Sep 2003, Kris Kennaway wrote: On Sun, Sep 21, 2003 at 01:44:35AM -0400, Daniel Eischen wrote: What, precisely, do you object to in the above proposal? 1, 2, and 3. I don't think backing out -pthread change helps much in fixing ports... Again, why? Please explain instead of asserting, because that's getting us nowhere towards resolving this. Because when things break, people fix them. There is no motivation (as seen in the last 2+ years) to fix something that isn't broken. Please also see: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=321307+0+archive/2003/freebsd-ports/20030601.freebsd-ports my posting to ports@ in May of this year. When the GCC-3.3 import broke a lot of ports, did you ask for it to be backed out so that ports could first be fixed? Yeah, OK, we're in a ports freeze, so that's different now. But once the freeze is lifted, I don't see a need to keep -pthread in (assuming it was added back for the freeze). -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
On Sun, Sep 21, 2003 at 02:12:55AM -0400, Daniel Eischen wrote: Because when things break, people fix them. There is no motivation (as seen in the last 2+ years) to fix something that isn't broken. Please also see: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=321307+0+archive/2003/freebsd-ports/20030601.freebsd-ports my posting to ports@ in May of this year. I wish you'd pushed the issue a bit more aggressively. Sometimes people don't pay close enough attention, and I am definitely one of those people. My apologies for missing that message. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The bikeshed T-shirt
On Sun, 21 Sep 2003, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Daniel Eischen [EMAIL PROTECTED] writes: : Can you add a no -pthread symbol to it? Can you give it a rest? You made a bad call, people are giving you grief for it. That is not a bikeshed. It's just a joke at my own expense. Sorry to imply otherwise. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The bikeshed T-shirt
In message: [EMAIL PROTECTED] Daniel Eischen [EMAIL PROTECTED] writes: : It's just a joke at my own expense. Sorry to imply otherwise. Yea. My snapping at you was out of line. I'm just a little frustrated and let it get the better of me. Please forgive me. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
On Sun, Sep 21, 2003 at 02:12:55AM -0400, Daniel Eischen wrote: On Sat, 20 Sep 2003, Kris Kennaway wrote: On Sun, Sep 21, 2003 at 01:44:35AM -0400, Daniel Eischen wrote: What, precisely, do you object to in the above proposal? 1, 2, and 3. I don't think backing out -pthread change helps much in fixing ports... Again, why? Please explain instead of asserting, because that's getting us nowhere towards resolving this. Because when things break, people fix them. There is no motivation (as seen in the last 2+ years) to fix something that isn't broken. What's the real issue here? It seems like you're suggesting that it's not your responsibility to help fix the broken ports, and that other people should do the work instead. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=321307+0+archive/2003/freebsd-ports/20030601.freebsd-ports my posting to ports@ in May of this year. That change doesn't seem to have happened, or to be the same thing we're discussing here. Anyway, if you'd been interested in pre-empting problems with the -pthread change you could have asked me to do a package build with the change in place to test the waters, and then worked with me and others to minimize the impact at the time when the commit went in. I routinely do this with other committers (including the gcc imports), and I'm happy to continue doing so. However, the strategy of just dumping a change into the tree and then leaving it to others to clean up the mess is not a good one - it's disruptive to the development cycle, it causes developers to get bogged down in arguments like we find ourselves having now, and the bottom line is that it's just not very polite to the people that your change affects. When the GCC-3.3 import broke a lot of ports, did you ask for it to be backed out so that ports could first be fixed? No, kan and I worked together before the change went in to evaluate the impact on packages, then I coordinated a group of volunteers to help fix the resulting fallout. I'm trying to do the same thing now. Are you willing to be part of the solution to this problem? Kris pgp0.pgp Description: PGP signature
re: StarOffice 6 under CURRENT
Hi, FreeBSD bart 5.1-CURRENT FreeBSD 5.1-CURRENT #2: Sat Sep 20 20:34:05 PDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BART i386 I am having problems running staroffice under current. My question is is anyone else eperiencing this problem? The initial ports install runs fine but when running setup.bin(via executible staroffice6) it fails: pid 657 (setup.bin), uid 1002: exited on signal 6 Any help is greatly appreciated! Sounds like linprocfs is not running anymore ? linprocfs on /usr/compat/linux/proc (linprocfs, loc Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
On Sat, 20 Sep 2003, Kris Kennaway wrote: On Sun, Sep 21, 2003 at 02:12:55AM -0400, Daniel Eischen wrote: On Sat, 20 Sep 2003, Kris Kennaway wrote: On Sun, Sep 21, 2003 at 01:44:35AM -0400, Daniel Eischen wrote: What, precisely, do you object to in the above proposal? 1, 2, and 3. I don't think backing out -pthread change helps much in fixing ports... Again, why? Please explain instead of asserting, because that's getting us nowhere towards resolving this. Because when things break, people fix them. There is no motivation (as seen in the last 2+ years) to fix something that isn't broken. What's the real issue here? It seems like you're suggesting that it's not your responsibility to help fix the broken ports, and that other people should do the work instead. Well, sorta yes. I don't have the time to fix broken ports but I can help guide others. I have other things on my plate. I do have one of my own ports to fix though. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=321307+0+archive/2003/freebsd-ports/20030601.freebsd-ports my posting to ports@ in May of this year. That change doesn't seem to have happened, or to be the same thing we're discussing here. Anyway, if you'd been interested in pre-empting problems with the -pthread change you could have asked me to do a package build with the change in place to test the waters, and then worked with me and others to minimize the impact at the time when the commit went in. I routinely do this with other committers (including the gcc imports), and I'm happy to continue doing so. Well, actually it is directly related. Part of the plan to transition to libpthread is making ports PTHREAD_LIBS compliant. As stated in that thread, if a libpthread exists on the system, autoconf/configure will pick it up and the port will also end up using -pthread and/or PTHREAD_LIBS. If PTHREAD_LIBS is set to libthr or libc_r (something other than libpthread), then the port ends up linking to both libraries. This doesn't work but you don't know it until your run the application and very weird things happen. Causing a clean breakage is better because you know at compile-time that something is wrong. So ports need to first be PTHREAD_LIBS compliant before we make the switch. Soon after ports are fixed, we can rename it. I think doing a build of all the ports is a good idea. I guess you've already done that if I recall an earlier email correctly. I also think most of the problems are already known, and if you give it a few days after the freeze things should look a lot better. Actually, to look ahead a bit... After ports are fixed, it still might be a good idea to do another package build, but this time with libkse installed as libpthread and PTHREAD_LIBS set to libc_r (or something that is not libpthread). Is there an easy way to do an 'ldd' of the resulting binaries to make sure libpthread isn't referenced? Feel free to take this offline if you want... However, the strategy of just dumping a change into the tree and then leaving it to others to clean up the mess is not a good one - it's disruptive to the development cycle, it causes developers to get bogged down in arguments like we find ourselves having now, and the bottom line is that it's just not very polite to the people that your change affects. As Will mentioned, I think the changes are mostly done. I don't think I just 'dumped' the changes into the tree. It has been over 2 years since, yada yada yada, and the ports system should have been using PTHREAD_LIBS since then. I don't want to argue with you; I respect you and everyone else here and God knows you guys contribute an awful lot. When the GCC-3.3 import broke a lot of ports, did you ask for it to be backed out so that ports could first be fixed? No, kan and I worked together before the change went in to evaluate the impact on packages, then I coordinated a group of volunteers to help fix the resulting fallout. I'm trying to do the same thing now. Are you willing to be part of the solution to this problem? From what I've recently read, the freeze should be lifting this week. Can we hold off till then? Is a few more days going to matter? If the freeze continues longer than expected, I'll back the change out until it's over. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
On Sun, Sep 21, 2003 at 03:17:28AM -0400, Daniel Eischen wrote: From what I've recently read, the freeze should be lifting this week. Can we hold off till then? Is a few more days going to matter? If the freeze continues longer than expected, I'll back the change out until it's over. I think we are going to extend it to allow more fixes for 4.9 since it's going to be delayed. But I'm not positive. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
IMHO if the ports tree is unfrozen for the -pthreads fixes, the 4.9 release schedule will drift days if not weeks. While it's not as apparent as the kernel build issues, there are significant QA issues that go into the ports system. That's why the freeze is in place, to allow the QA process to run its course. Executive summary: POLA was violated for all the ports maintainers who do not keep up with kernel intricacies. Dismissing their distress at this doesn't really help the project move along. mcl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_sk build fails
On Sat, 20 Sep 2003 16:14:22 +0200 Pawel Worach [EMAIL PROTECTED] wrote: Hi! Last if_sk update broke buildkernel === sk rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/../include /usr/src/sys/modules/sk/../../pci/if_sk.c /usr/src/sys/pci/if_sk.c:129:26: pci/yukonreg.h: No such file or directory mkdep: compile failed missed to cvs add yukonreg.h? - Pawel This was fixed sometime yesterday with a commit of yukonreg.h. Regards, Stuart ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
I don't think committing fixes for -current breakages should cause problems for 4.9-RELEASE (especially with the caveat that they be compile tested on -stable). It takes several days to do the compile QA. That's assuming that no actual users are allowed to have time to test the changes before the release is cut. IMHO, what you think just doesn't reflect the actual reality involved. We are just going to have to disagree on this. You should really look at the bento logs and get an understanding of the continual QA that is done on the _over_ 9000 ports (many of which have _no_ maintainer signed up) before you make assumptions that there shouldn't be significant problems with what you propose. mcl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
On Sun, 21 Sep 2003, Will Andrews wrote: On Sun, Sep 21, 2003 at 03:17:28AM -0400, Daniel Eischen wrote: From what I've recently read, the freeze should be lifting this week. Can we hold off till then? Is a few more days going to matter? If the freeze continues longer than expected, I'll back the change out until it's over. I think we are going to extend it to allow more fixes for 4.9 since it's going to be delayed. But I'm not positive. OK, instead of waiting for it to be delayed, I backed out the -pthread removal until it's over. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
On Sun, 21 Sep 2003, Daniel Eischen wrote: Well, actually it is directly related. Part of the plan to transition to libpthread is making ports PTHREAD_LIBS compliant. As stated in that thread, if a libpthread exists on the system, autoconf/configure will pick it up and the port will also end up using -pthread and/or PTHREAD_LIBS. If PTHREAD_LIBS is set to libthr or libc_r (something other than libpthread), then the port ends up linking to both libraries. This doesn't work but you don't know it until your run the application and very weird things happen. Causing a clean breakage is better because you know at compile-time that something is wrong. So ports need to first be PTHREAD_LIBS compliant before we make the switch. Soon after ports are fixed, we can rename it. Where the ports are concerned, I think this is a reasonable course of action, and I'd like to thank you for backing out the -pthread change on HEAD. I am a little confused about one thing though. What is going to happen to third party apps that use -pthread that aren't compiled through the ports? Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
On Sun, Sep 21, 2003 at 01:25:09AM -0700, Doug Barton wrote: I am a little confused about one thing though. What is going to happen to third party apps that use -pthread that aren't compiled through the ports? They need to replace -pthread with their thread library of choice (e.g. -lc_r or -lpthread). -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
On Sun, 21 Sep 2003, Doug Barton wrote: On Sun, 21 Sep 2003, Daniel Eischen wrote: Well, actually it is directly related. Part of the plan to transition to libpthread is making ports PTHREAD_LIBS compliant. As stated in that thread, if a libpthread exists on the system, autoconf/configure will pick it up and the port will also end up using -pthread and/or PTHREAD_LIBS. If PTHREAD_LIBS is set to libthr or libc_r (something other than libpthread), then the port ends up linking to both libraries. This doesn't work but you don't know it until your run the application and very weird things happen. Causing a clean breakage is better because you know at compile-time that something is wrong. So ports need to first be PTHREAD_LIBS compliant before we make the switch. Soon after ports are fixed, we can rename it. Where the ports are concerned, I think this is a reasonable course of action, and I'd like to thank you for backing out the -pthread change on HEAD. I am a little confused about one thing though. What is going to happen to third party apps that use -pthread that aren't compiled through the ports? They'll have to choose one of our threading libraries. -pthread will be a NOOP for them, so their application will fail to link. If the third party application is a library, it won't be as obvious because it won't cause a compile or link error. This holds true for ports also. It might not be that much of a problem though, because applications that link to the third party library can always link to whatever threads library they want. Then the third party library would end up using the threads library chosen by the application. This might be the way to go for OpenGL or other similar libraries. It allows you to have applications linked with different thread libraries and not be broken by OpenGL (or whatever) being explicitly linked to a different threads library than the application. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
CIS is too long
FreeBSD 5.1-CURRENT #0: Sat Sep 20 11:38:46 JST 2003 Sep 20 12:47:38 daemon kernel: [EMAIL PROTECTED]:/home/niioka/src/obj/usr/src/sys/DAEMON I'm getting the following errors when I insert my pccard. CIS is too long -- truncating pccard0: Card has no functions! cbb0: PC Card card activation failed I tried to make buildkernel and installkernel with OLDCARD, and I'm getting the following messages wheh I insert my pccard. So, I can use the Panasonic KX-PH402D card. pccard: card inserted, slot 0 Sep 21 16:30:40 daemon pccardd[188]: Card Panasonic(KX-PH402D) [] [[none]] matched Panasonic (KX-PH402D) [(null)] [(null)] sio0 at port 0x2f8-0x2ff irq 9 slot 0 on pccard0 sio0: type 16550A sio0: unable to activate interrupt in fast mode - using normal mode Sep 21 16:30:45 daemon pccardd[188]: sio0: Panasonic (KX-PH402D) inserted. I want to know how can I use my pccard with GENERIC kernel. Regards. -- Kenichi Niioka ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ncurses-5.3 buggy under 5.1-current
Hi! The installation of the ncurses-5.3 port leaves the system unusable for apps needing libncurses e.g. vi, sysinstall... The characters on output are severely scrambled. Its desinstallation solves the problem (the ncurses-5.2 from src/contrib works fine with 5.1-current). But some good ports require ncurses-5.3! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Unable to newfs/fsck partition on -current because of write failed.
I'm running -current from september, 14 on my notebook. After an unclean shutdown (out of batteri) my /var filesystem died horrible. Now when i'm trying to do a fsck I always get write failed for a lot of blocks. I saw this error some months ago where I just wiped the fs with newfs. But now even newfs gives me Write failed. This seems a bit odd because i can easily do a dd if=/dev/zero of=/dev/ad0s2d and clear out the label. Any hints ? I'm thinking geom and/or blocksize problems. But that's just a guess. -- Cheers, Nicolai Petri ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to newfs/fsck partition on -current because of write failed.
* Nicolai Petri [EMAIL PROTECTED] [2003-09-21 12:23]: But now even newfs gives me Write failed. This seems a bit odd because i can easily do a dd if=/dev/zero of=/dev/ad0s2d and clear out the label. Any hints ? I'm thinking geom and/or blocksize problems. But that's just a guess. There was a small window in which the -CURRENT kernel was broken. This happened just around September 14th, so I suggest you either upgrade your kernel or use a kernel built before September 14th. Regards -Thorsten -- Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
-current on laptop: panic: m_free detected a mbuf double free
Update the status now on -current.
I downloaded the last recent snapshot of 2003-09-20 from current.freebsd.org.
Made a test ftp session using the live CDROM. Same like a week before.
Panic if I download something big from my FreeBSD ftp server.
5.1 on my normal PIII PC works fine. This seems to be PCMCIA
related.
db trace
Debugger(...
panic(...
m_free(...
m_freem(...
ip_input(...
swi_net(...
ithread_loop(...
fork_exit(...
fork_trampoline(...
On Sun, Sep 14, 2003 at 09:46:47PM +0200, Andreas Klemm wrote:
On Sat, Sep 13, 2003 at 08:35:06PM -0400, Matthew N. Dodd wrote:
On Sun, 14 Sep 2003, Andreas Klemm wrote:
It works for me, xl0 card is recognized.
Great!
But during heavy ftp network traffic the LAPTOP panics.
machine paniced 2 times
A) one time after transferring ~90 MB of a ~300 MB large ISO image
B) 2nd time after transferring ~ 8 MB of same large file
C) 3rd time after transferring ~ 6 MB of same large file
In DDB I see using where, that the machine always crashes within
the same functions. DDB tells me:
to B) panic: m_free detected a mbuf double-free
Debugger(panic)
Stopped at Debugger+0x54:xchgl %ebx,in_Debugger.0
db where
Debugger
panic
m_free
m_freem
ip_input -- happens at different functions
...
db panic
...
to C) panic: m_free detected a mbuf double-free
Debugger(panic)
Stopped at Debugger+0x54:xchgl %ebx,in_Debugger.0
db where
Debugger
panic
m_free
m_freem
xl_txeof --- happens at different functions
xl_intr
cbb_intr
ithread_loop
fork_exit
fork_trampoline
--- trap 0x1, eip = 0, esp = 0xcb042d7c, ebp = 0 ---
db panic
panic: from debugger
Uptime: 2m55s
Dumping 191M
Dump complete
Let's see what gdb tells me, from panic B)
Sorry for case C) I didn't have enough space :-(
(kgdb) where
#0 doadump
#1 0x... in boot (howto=260) at ../../../kern/kern_shutdown.c: 372
#2 0x... in panic () at ../../../kern/kern_shutdown.c: 550
#3 0x... in db_panic () at ../../../ddb/db_command.c: 450
#4 0x... in db_command (...) at ../../../ddb/db_command.c: 346
#5 0x... in db_command_loop () at ../../../ddb/db_command.c: 472
#6 0x... in db_trap (type=3, code=0) at ../../../ddb/db_trap.c: 73
#7 0x... in kdb_trap (type=3, code=0, regs=0xcb027bc6)
at ../../../i386/i386/db_interface.c: 171
#8 0x... in trap (frame=
{tf_fs = 24, tf_es = -1039597552, tf_ds = 16, tf_edi = 1, tf_esi )
-1070431840, tf_ebp = -889029704, tf_isp = -889029736, tf_ebx = 0, tf_edx = 0,
tf_ecx = 32, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1070703196, tf_cs =
8, tf_eflags = 642, tf_esp = -1070363254, tf_ss = -1070440292})
at ../../../i386/i386/trap.c: 577
#9 0x... in calltrap () at {standard input}: 102
#10 0x... in panic (fmt=0xc03281a0 m_free detected a mbuf double-freeze)
at ../../../kern/kern_shutdown.c: 534
#11 0x... in m_free (mb=0xc0d4fe00) at ../../../kern/subr_mbuf.c: 1368
#12 0x... in m_freem (mb=0x0) at ../../../kern/subr_mbuf.c: 1403
#13 0x... in ip_input (mb=0xc0d4fe00) at ../../../netinet/ip_input.c: 963
#14 0x... in swi_net (dummy=0x0) at ../../../net/net_isr.c: 236
#15 0x... in ithread_loop (arg=0xc0d33200)
at ../../../kern/kern_intr.c: 534
#16 0x... in fork_exit (callout=0xc01b3900 ithread_loop, arg=0x0,
frame=0x0) at ../../../kern/kern_fork.c: 796
(kgdb) up 8
#8 0x... in trap (frame=
{tf_fs = 24, tf_es = -1039597552, tf_ds = 16, tf_edi = 1, tf_esi )
-1070431840, tf_ebp = -889029704, tf_isp = -889029736, tf_ebx = 0, tf_edx = 0,
tf_ecx = 32, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1070703196, tf_cs =
8, tf_eflags = 642, tf_esp = -1070363254, tf_ss = -1070440292})
577 if (kbd_trap (type, 0, frame)
(kgdb) frame frame-tf_ebp frame-tf_eip
Too many args in frame specification ...
h /%(/%( does the developer handbook need and update ? ;-)
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html#KERNELDEBUG-GDB
Here it ends , have no clue how to select correct frames ... :-)
Andreas ///
--
Andreas Klemm - Powered by FreeBSD 5.1-CURRENT
Need a magic printfilter today ? - http://www.apsfilter.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
To unsubscribe, send any mail to [EMAIL PROTECTED]
Andreas ///
--
Andreas Klemm - Powered by FreeBSD 5.1-CURRENT
Need a magic printfilter today ? - http://www.apsfilter.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
-current brake ufs for -stable
Hello! I've installed both -current and -stable on my box. One of partition I plan to share betwen them (place ports/distfiles there). I newfs'ed it from -stable and wrote on it from -current. When I booted with -stable I've found the partition FS was broken. I think it's because of extended atributes -current wrote on it. I don't like to turn off extended attributes on -current at all. I'd like to have some option for mount to disable it (I've not found it on manpage). How can I use the partition this way now? Sem. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: really 4.9 stability
On Sat, Sep 20, 2003 at 09:14:40PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Frank Mayhar [EMAIL PROTECTED] writes: : Everything has been rock-solid, no problems at all. Were it not for : PAE, I would say to go ahead and release it. That's good to hear. The re@ folks at devsummit had said that even w/o PAE enabled, bad things were happening to people. However, I've seen a number of reports since then that contradict this, or that the instability isn't that common. I'm confused; how does one disable PAE? I don't see a kernel option for it. Ceri -- User: DO YOU ACCEPT JESUS CHRIST AS YOUR PERSONAL LORD AND SAVIOR? Iniaes: Sure, I can accept all forms of payment. -- www.chatterboxchallenge.com pgp0.pgp Description: PGP signature
make release and md(4) problem
Hi, when doing my first make release I noticed it stopped somewhere and hung :( 74830 p2 D+ 0:01.12 cpio -dump /mnt The host is i386 and TARGET ist sparc64 just to confuse. The base system runs a HEAD world/kernel from mid july. The above cpio must be from src/release/sparc64/mkisoimages.sh unlucky me tried to see what's going on and did a ls /u3/mnt which also hung. more unlucky me also typed in sync in another screen. kill -9 on the processes did not help. After another sync I am no longer able to remotely do anything with the machine apart from successfully pinging it. Somewhere in between I tried to ktrace the processes but didn't get any output. This is what strace said: abcde# strace -p 74883 # ls getdirentries(3, ^C unfinished ... abcde# strace -p 74830 # cpio write(4, ., 512^C unfinished ... abcde# strace -p 74920 # sync sync(0^C unfinished ... I found an older PR http://www.freebsd.org/cgi/query-pr.cgi?pr=47538 that might be related. How are snapshots and release builds done by others ? Or are things already fixed and I should update base system to latest head (thinking about atang) ? and btw: are /dev/mdXc supposed to be existent as given in the release Makefiles/scripts ? Thanks for any comments. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt
On Sat, 2003-09-20 at 22:53, Thomas Quinot wrote: Le 2003-09-20, Daniel Eischen écrivait : No, using latest sources, with or without atapicam, does not solve the problem. It still hangs. Please try the patch below, it should at least work around the problem. I have rebuilt world after you have committed the patch and now the system boots properly with ATAPICAM enabled in the kernel. It no longer hangs at boot. I tried mounting /dev/cd0 and suceeded. However, not everything seems to be perfect, take a look at the bottom of the included dmesg output: === Copyright (c) 1992-2003 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 5.1-CURRENT #0: Sun Sep 21 15:44:22 EEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/JAGO Preloaded elf kernel /boot/kernel/kernel at 0xc04b6000. Preloaded elf module /boot/kernel/linux.ko at 0xc04b61f4. Preloaded elf module /boot/kernel/acpi.ko at 0xc04b62a0. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) processor (1400.06-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x644 Stepping = 4 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc044RSVD,AMIE,DSP,3DNow! real memory = 536805376 (511 MB) avail memory = 516239360 (492 MB) Pentium Pro MTRR support enabled VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc03c82c2 (122) VESA: NVidia npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: GBTAWRDACPI on motherboard pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00fddb0 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU port 0x530-0x537 on acpi0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 7 INTD is routed to irq 5 pcib0: slot 7 INTD is routed to irq 5 pcib0: slot 10 INTA is routed to irq 11 pcib0: slot 14 INTA is routed to irq 11 agp0: AMD 761 host to AGP bridge port 0xc000-0xc003 mem 0xe400-0xe4000fff,0xe000-0xe1ff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci_cfgintr: 1:5 INTA BIOS irq 10 pci1: display, VGA at device 5.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686B UDMA100 controller port 0xc400-0xc40f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] uhci0: VIA 83C572 USB controller port 0xc800-0xc81f irq 5 at device 7.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xcc00-0xcc1f irq 5 at device 7.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: serial bus, SMBus at device 7.4 (no driver attached) rl0: RealTek 8139 10/100BaseTX port 0xe000-0xe0ff mem 0xe4001000-0xe40010ff irq 11 at device 10.0 on pci0 rl0: Ethernet address: 00:e0:7d:9f:be:31 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcm0: Creative CT5880-C port 0xe400-0xe43f irq 11 at device 14.0 on pci0 pcm0: SigmaTel STAC9708/11 AC97 Codec atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 orm0: Option ROM at iomem 0xc-0xcefff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter TSC frequency 1400061468 Hz quality 800 Timecounters tick every 10.000 msec acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0% GEOM: create disk ad0 dp=0xc40a3a70 ad0: 38182MB MAXTOR 4K040H2 [77578/16/63] at ata0-master UDMA100 GEOM: create disk ad1 dp=0xc40a3070 ad1: 16446MB ST317221A [33416/16/63] at ata0-slave UDMA66 acd0: CDRW LITE-ON COMBO LTC-48161H at ata1-master PIO4 (probe2:ata1:0:0:0): Recovered Sense (probe2:ata1:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe2:ata1:0:0:0): CAM Status: SCSI Status Error (probe2:ata1:0:0:0): SCSI Status: Check Condition (probe2:ata1:0:0:0): ILLEGAL REQUEST asc:24,0 (probe2:ata1:0:0:0): Invalid field in CDB (probe2:ata1:0:0:0): Recovered Sense (probe2:ata1:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0
Panic: Fatal trap 12: page fault while in kernel mode
Hi, I was playing around with CAM and got this reproducible panic: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x46 fault code = supervisor read, page not present instruction pointer = 0x:0xc03962fe stack pointer = 0x10:0xd835b9b4 frame pointer = 0x10:0xd835ba24 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 585 (dvdtest) kernel: type 12 trap, code=0 Stoppes at generic_bcopy+0x1a: repe mocsl (%esi),%es:(%edi) db tr generic_bcopy(c4034780,c4205000,d835ba58,c0136c42,c4034780) at generic_bcopy+0x1a sbp_action(c4034780,c4205000,c0136953,c41f1400,c4205000) at sbp_action+0x18 xpt_run_dev_sendq(c4034740,c41f1418,0,d835ba8c,c027895f)at xpt_run_dev_dendq+0x192 xtp_action(c4205000,0,c41f1430,c4202000,c4205000) at xpt_action+0x238 cam_periph_runccb(c4205000,0,2,1,c40fb960) at cam_periph_runccb+0x48 passsendcbb(c41e6500,c4205000,c4203400,c462920) at passsendccb+0xc7 passioctl(c4213100,c2601502,c4203400,3,c401fbe0) at passioctl+0xf0 spec_ioctl(d835bb7c,d835bc28,c02c34a1,d835bb7c,c025454d) at spec_ioctl+0x19e spec_vnoperate(d835bb7c,c025454d,c0460ea0,1,c0447b00) at spec_vnoperate+0x18 vn_ioctl(c422c330,c2601502,c4203400,c42c9480,c401fbe0) at vn_ioctl+0x1a1 ioctl(c401fbe0,d835bd10,c03f9491,3ec,3) at ioctl+0x475 syscall(2f,2f,2f,bfbffb90,bfbff910) at syscall+0x273 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281a354f, esp = 0xbfbff8dc, ebp = 0xbfbff8f8 --- db Kernel is from this morning with up to date sources and ATAPICAM built in: FreeBSD cheops.phoenix 5.1-CURRENT FreeBSD 5.1-CURRENT #7: Sun Sep 21 14:05:38 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CHEOPS i386 If you need further information or the source that caused the panic, please let me know. Regards, Markus -- GPG Pub-Key: http://www.phoenix-systems.de/mbrueffer.asc GPG Fingerprint: 3F9B EBE8 F290 E5CC 1447 8760 D48D 1072 78F8 A8D4 GPG Key ID : 0x78F8A8D4 pgp0.pgp Description: signature
Re: Getting -pthread support back into local source tree
Scot W. Hetzel wrote:
From: Dan Naumov [EMAIL PROTECTED]
Seeing as -pthread support has been removed from -CURRENT breaking
_LOTS_ of ports, is it possible to get it back into a local source
tree ? If so, how ? Thanks in advance.
All you need to do is add:
CONFIGURE_ENV+=PTHREAD_LIBS=${PTHREAD_LIBS} \
PTHREAD_CFLAGS=${PTHREAD_CFLAGS}
To the port that is broken by having -pthread support removed, then compile
the port.
If it still fails to compile, then you'll need to add a sed command to the
port that replaces -pthread with ${PTHREAD_LIBS} and -DTHREAD_SAFE with
${PTHREAD_LIBS} in the configure script or the Makefiles.
Well, that'd fit my skills, but what is for example with the jdk13? I
have no idea how to fix this one.
Thanks,
-Harry
After you have it working, send-pr your patch to gnats and the port
maintainer. This is the only way to get these problems fixed, if the port
maintainer doesn't have time to fix the port to work on -CURRENT.
Scot
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sound card troubles
On Sat, 20 Sep 2003 23:07:10 -0700 (PDT) Doug White [EMAIL PROTECTED] wrote: On Sat, 20 Sep 2003, Bruce Mackay wrote: Hey all, I get the following hang up when I try booting up, here's the problem area... pcm0: Intel ICH3 (82801CA) at device 31.5 on pci0 pcm0: unable to map IO port space device_probe_and_attach: pcm0 attach returned 6 I'm running a CVSUP -current from Thu Sep 18 12:34:00 EDT 2003, I have a Yamaha YMF753 Codex Chip and it's Sound Blaster Pro compatible card, anyone have any suggestions? Try setting the tunable hw.pci.allow_unsupported_io_range to 1 in loader.conf and booting. Your machine appears to need special consideration; most ICH3 chips don't need this option. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org snip I actually tried hw.pci.allow_unsupported_io_range = 1 to no avail. I've tried building pcm into my kernel, I've tried loading them as modules with no success. I was reading somewhere that I may need hw.pci.enable_io_modes = 1 to use my sound card. However I cannot boot unless I set hw.pci.enable_io_modes = 0. Any ideas on how I can get around this? Or if this will even help... Thanks, Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt
Le 2003-09-21, Dan Naumov écrivait : (probe2:ata1:0:0:0): Recovered Sense (probe2:ata1:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe2:ata1:0:0:0): CAM Status: SCSI Status Error (probe2:ata1:0:0:0): SCSI Status: Check Condition (probe2:ata1:0:0:0): ILLEGAL REQUEST asc:24,0 (probe2:ata1:0:0:0): Invalid field in CDB That's fine, it just means your drive does not provide serial number information. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt
Le 2003-09-21, Bryan Liesner écrivait : The patch doesn't take care of the hang for me. Does it change anything, or do you still see the 'REQUEST_SENSE recovered from missing interrupt'? Is your source tree up-to-date? Several fixes have been committed to both the ATA and the CAM subsystems recently, that address problems uncovered by the transition to ATAng. Did anyone read _any_ of my previous posts? Certainly so, since you already received answers to some of them. If you'd like to help speed up the resolution of the problems you see, maybe you could provide a backtrace at the point where your system hangs, and a log of boot -v output, with the CAMDEBUG and CAM_DEBUG_FLAGS=CAM_DEBUG_CCB options. Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CIS is too long
In message: [EMAIL PROTECTED] Kenichi Niioka [EMAIL PROTECTED] writes: : I'm getting the following errors when I insert my pccard. : : CIS is too long -- truncating : pccard0: Card has no functions! : cbb0: PC Card card activation failed There's a small set of cards that aren't being read in correctly. You have one of the cards. It looks like I'm programming the bridges exactly the same between oldcard and newcard. I do not know why it isn't working, maybe a bad delay? maybe some bit I've overlooked? I'm not sure. I see it in maybe 3 of the hundred odd cards that I have. These cards read '0's. I have one other one that reads just freaky random junk. : [[ OLDCARD working ]] yes. I see the same thing. : I want to know how can I use my pccard with GENERIC kernel. That might be a little difficult until this bug is fixed. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt
Le 2003-09-21, Shin-ichi Yoshimoto écrivait : I could not get a backtrace because infinite loop occured like this: Can't you drop into DDB at that point? Also, do you have up-to-date sources? Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt
On Sun, 21 Sep 2003, Thomas Quinot wrote: Le 2003-09-21, Bryan Liesner écrivait : The patch doesn't take care of the hang for me. Does it change anything, or do you still see the 'REQUEST_SENSE recovered from missing interrupt'? Is your source tree up-to-date? Several fixes have been committed to both the ATA and the CAM subsystems recently, that address problems uncovered by the transition to ATAng. It slightly changes things for me; I can eventually get the system to boot, but I get a boatload of infinite messages: Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): CAM Status: SCSI Status Error Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): SCSI Status: Check Condition Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): Recovered Sense Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): CAM Status: SCSI Status Error Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): SCSI Status: Check Condition Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): Recovered Sense Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): CAM Status: SCSI Status Error Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): SCSI Status: Check Condition Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): Recovered Sense ... and I have to reboot. This is with atapicam in the kernel. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt
Le 2003-09-21, Daniel Eischen écrivait : Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): CAM Status: SCSI Status Error Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): SCSI Status: Check Condition Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): Recovered Sense Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): CAM Status: SCSI Status Error Um, strange, this is exactly what cam_periph.c rev. 1.53 was supposed to fix. Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CIS is too long
- Original Message - From: M. Warner Losh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, September 21, 2003 5:50 PM Subject: Re: CIS is too long In message: [EMAIL PROTECTED] Kenichi Niioka [EMAIL PROTECTED] writes: : I'm getting the following errors when I insert my pccard. : : CIS is too long -- truncating : pccard0: Card has no functions! : cbb0: PC Card card activation failed There's a small set of cards that aren't being read in correctly. You have one of the cards. It looks like I'm programming the bridges exactly the same between oldcard and newcard. I do not know why it isn't working, maybe a bad delay? maybe some bit I've overlooked? I'm not sure. I see it in maybe 3 of the hundred odd cards that I have. These cards read '0's. I have one other one that reads just freaky random junk. I have a wireless card that I get random junk for too, yet netbsd reads the CIS just fine.. unfortuneatly my laptop is somewhat out of commission at the moment so I can't really dig in to it :/ It's a shame, because I'd like to be able to port a driver for it. Regards, Stuart ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt
On Sun, 21 Sep 2003, Thomas Quinot wrote: Le 2003-09-21, Daniel Eischen écrivait : Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): CAM Status: SCSI Status Error Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): SCSI Status: Check Condition Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): Recovered Sense Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): CAM Status: SCSI Status Error Um, strange, this is exactly what cam_periph.c rev. 1.53 was supposed to fix. I guess I didn't get that update; I'm still using 1.52. I'll try another cvsup and update. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: X10 Wireless Technology Inc USB Receiver
Hi,
I'm trying to get the USB RF remote control that comes with some ATI
Wonder cards to do something meaningful under -current.
It shows up as an X10 Wireless Technology Inc USB Receiver with three
devices: /dev/ugen0, and the corresponding input (/dev/ugen0.1) and
output endpoints (/dev/ugen/0.2). Also see the attached usbctl output.
Simply reading from the input endpoint /dev/ugen0.1 doesn't work.
This page (http://remotew.free.fr/linux_en.htm) points at the Gatos
project, which has a Linux driver (ati_remote) that seems to make the
remote show up as a USB keyboard:
http://sourceforge.net/project/showfiles.php?group_id=12629
That driver sends a couple of magic bytes to the device during
initialization. I'm trying to do the same from userland:
static char init1[]= { 0x80, 0x01, 0x00, 0x20, 0x14 };
static char init2[]= { 0x80, 0x01, 0x00, 0x20, 0x14, 0x20, 0x20, 0x20 };
int main(int argc, char *argv[]) {
int out = open(/dev/ugen0.2, O_WRONLY);
if (out == -1) {
perror(ugen0.2);
goto done;
}
if (write(out, init1, sizeof init1) == -1) {
perror(write init1);
goto done;
}
if (write(out, init2, sizeof init2) == -1) {
perror(write init1);
goto done;
}
done:
close(out);
}
Really simply. Here's what happens when I run it:
write init1: Input/output error
it feels like I'm missing something extremely obvious, but I'm new to
the USB internals. The two endpoints are interrupt endpoints. I'm not
sure what that signifies, but I heard writing to them on -stable is
broken, but on -current it should work.
Any ideas?
Thanks,
Lars
--
Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute
DEVICE addr 2
DEVICE descriptor:
bLength=18 bDescriptorType=device(1) bcdUSB=1.10 bDeviceClass=0 bDeviceSubClass=0
bDeviceProtocol=0 bMaxPacketSize=8 idVendor=0x0bc7 idProduct=0x0004 bcdDevice=100
iManufacturer=1(X10 Wireless Technology Inc) iProduct=2(USB Receiver)
iSerialNumber=0() bNumConfigurations=1
CONFIGURATION descriptor 0:
bLength=9 bDescriptorType=config(2) wTotalLength=32 bNumInterface=1
bConfigurationValue=1 iConfiguration=0() bmAttributes=80 bMaxPower=2 mA
INTERFACE descriptor 0:
bLength=9 bDescriptorType=interface(4) bInterfaceNumber=0 bAlternateSetting=0
bNumEndpoints=2 bInterfaceClass=255 bInterfaceSubClass=0
bInterfaceProtocol=0 iInterface=0()
ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=1-in
bmAttributes=interrupt wMaxPacketSize=8 bInterval=10
ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=2-out
bmAttributes=interrupt wMaxPacketSize=8 bInterval=10
current configuration 1
smime.p7s
Description: S/MIME Cryptographic Signature
Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt
Subject: Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt, On Sun, 21 Sep 2003 18:57:43 +0200, Thomas Quinot wrote: Can't you drop into DDB at that point? Ok, I will try it. Also, do you have up-to-date sources? Yes, of course. I have recent ones. -- Shin-ichi YOSHIMOTO [EMAIL PROTECTED] http://diary.waishi.jp/~yosimoto/diary/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ncurses-5.3 buggy under 5.1-current
On Sun, 2003-09-21 at 17:37, [EMAIL PROTECTED] wrote: what sort of bugs? (and is this a problem with the port, rather than ncurses). From: Vitalis ([EMAIL PROTECTED]) Subject: ncurses-5.3 buggy under 5.1-current This is the only article in this thread View: Original Format Newsgroups: mailing.freebsd.current Date: 2003-09-21 02:41:08 PST Hi! The installation of the ncurses-5.3 port leaves the system unusable for apps needing libncurses e.g. vi, sysinstall... The characters on output are severely scrambled. Its desinstallation solves the problem (the ncurses-5.2 from src/contrib works fine with 5.1-current). But some good ports require ncurses-5.3! what sort of bugs? The output is unreadable: control characters such as newline characters are discarded so that vi shows the whole files on one huge line. It's the same thing with sysinstall; we can not navigate within it and it dumps core after a few second. (and is this a problem with the port, rather than ncurses). I don't know... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt
On Sun, 21 Sep 2003, Thomas Quinot wrote: Le 2003-09-21, Bryan Liesner écrivait : The patch doesn't take care of the hang for me. Does it change anything, or do you still see the 'REQUEST_SENSE recovered from missing interrupt'? Is your source tree up-to-date? Several fixes have been committed to both the ATA and the CAM subsystems recently, that address problems uncovered by the transition to ATAng. Did anyone read _any_ of my previous posts? Certainly so, since you already received answers to some of them. Thanks, the hang problems are fixed now. In an earlier post, I pointed out the commit that seemed to break things. Immediately after a commit to ata-queue.c, the hangs started. I was incorrectly thinking that this commit caused the problem, instead of uncovering a problem that was hiding somewhere else. No one told me that I was barking up the wrong tree... -Bryan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports and -current
John Birrell wrote: On Sat, Sep 20, 2003 at 08:06:25PM -0600, M. Warner Losh wrote: At the very least, we should put [-pthread] back as a noop. The timing on this really sucks because it breaks the ports tree for an extended period of time. While the fixes are simple, they haven't been made yet. The fact that the tree is frozen makes it seem like a really bad time to make the change. Yes, I think it should go back as a noop (mostly to satisfy the GCC people though). Perhaps put it back as a noop with a particularly loud warning: Warning: -pthread does nothing. If this is a port, complain to the maintainer to fix it. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports and -current
In message: [EMAIL PROTECTED] Tim Kientzle [EMAIL PROTECTED] writes: : John Birrell wrote: : On Sat, Sep 20, 2003 at 08:06:25PM -0600, M. Warner Losh wrote: : At the very least, we should put [-pthread] back as a noop. The timing on : this really sucks because it breaks the ports tree for an extended : period of time. While the fixes are simple, they haven't been made : yet. The fact that the tree is frozen makes it seem like a really bad : time to make the change. : : : Yes, I think it should go back as a noop (mostly to satisfy the GCC : people though). : : Perhaps put it back as a noop with a particularly : loud warning: : : Warning: -pthread does nothing. If this is a port, complain to the : maintainer to fix it. Maybe we should just stick to the plan that Kris and Daniel worked out? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt
Subject: Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt, On Mon, 22 Sep 2003 03:01:28 +0900, Shin-ichi Yoshimoto wrote: Ok, I will try it. I tried to cvsup and make build installkernel. This kernel said: [snip] acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0% GEOM: create disk ad0 dp=0xc63f6570 ad0: 239372MB Maxtor 7Y250P0 [486344/16/63] at ata0-master UDMA100 acd0: DVDR MATSHITADVD-RAM LF-D521 at ata1-master UDMA66 (probe2:ata1:0:0:0): Recovered Sense (probe2:ata1:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe2:ata1:0:0:0): CAM Status: SCSI Status Error (probe2:ata1:0:0:0): SCSI Status: Check Condition (probe2:ata1:0:0:0): ILLEGAL REQUEST asc:24,0 (probe2:ata1:0:0:0): Invalid field in CDB (probe2:ata1:0:0:0): Recovered Sense (probe2:ata1:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe2:ata1:0:0:0): CAM Status: SCSI Status Error (probe2:ata1:0:0:0): SCSI Status: Check Condition (probe2:ata1:0:0:0): ILLEGAL REQUEST asc:24,0 (probe2:ata1:0:0:0): Invalid field in CDB SMP: AP CPU #1 Launched! cd0 at ata1 bus 0 target 0 lun 0 cd0: MATSHITA DVD-RAM LF-D521 A111 Removable CD-ROM SCSI-0 device cd0: 66.000MB/s transfers cd0: cd present [2236704 x 2048 byte records] Mounting root from ufs:/dev/ad0s1a [end] Thanks, Thomas !! -- Shin-ichi YOSHIMOTO [EMAIL PROTECTED] http://diary.waishi.jp/~yosimoto/diary/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ATAng drives not probed
I'm getting intermittent problems on boot, sometimes it boots, most of the time not. When it stop it's at: ata0-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin dmesg -v from a full boot: http://am-productions.biz/docs/dmesg.txt -- Anish Mistry pgp0.pgp Description: signature
Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt
On Sun, 21 Sep 2003, Daniel Eischen wrote: On Sun, 21 Sep 2003, Thomas Quinot wrote: Le 2003-09-21, Daniel Eischen écrivait : Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): CAM Status: SCSI Status Error Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): SCSI Status: Check Condition Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): Recovered Sense Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Sep 21 12:40:28 sirius kernel: (cd0:ata0:0:0:0): CAM Status: SCSI Status Error Um, strange, this is exactly what cam_periph.c rev. 1.53 was supposed to fix. I guess I didn't get that update; I'm still using 1.52. I'll try another cvsup and update. That seemed to do the trick. No hangs and no infinite loopy messages. Thanks! -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sound card troubles
On Sun, 21 Sep 2003, Bruce Mackay wrote: I actually tried hw.pci.allow_unsupported_io_range = 1 to no avail. I've tried building pcm into my kernel, I've tried loading them as modules with no success. I was reading somewhere that I may need hw.pci.enable_io_modes = 1 to use my sound card. However I cannot boot unless I set hw.pci.enable_io_modes = 0. Any ideas on how I can get around this? Or if this will even help... You might check that your BIOS has PnP OS set to No, and try wiping the device configuration. You may just be screwed :( -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
On Sun, 21 Sep 2003, John Birrell wrote: On Sun, Sep 21, 2003 at 01:25:09AM -0700, Doug Barton wrote: I am a little confused about one thing though. What is going to happen to third party apps that use -pthread that aren't compiled through the ports? They need to replace -pthread with their thread library of choice (e.g. -lc_r or -lpthread). E... I'm not sure this is an optimal solution. There is an awful lot of software out there which expects -pthread to just work. Wouldn't it make more sense to default it to one thing or the other, then make it configurable (isn't this what libmap.conf is supposed to help with)? Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.9 stability update
On Fri, Sep 19, 2003 at 06:35:12PM +1000, Peter Jeremy wrote: On Thu, Sep 18, 2003 at 11:21:20PM -0600, Scott Long wrote: We'd like to get a new poll on the stability and readiness of 4.9. Last night I upgraded my laptop and it hung partway thru the boot (immediately after the pcm0: line in the dmesg below). Powering it off and back on made it boot normally. It's not done this before and I don't know whether to blame this on a glitch or the new kernel. Please ignore this problem and sorry for replying without checking the mailing list. (It was a newly built system with a newly updated CVS repository, but someone forgot the 'cvs update' in between). I do have some problems with 4.9 but I'm discussing that in -stable. Mea culpa. Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -current brake ufs for -stable
On Sun, 21 Sep 2003, Sergey Matveychuk wrote: I've installed both -current and -stable on my box. One of partition I plan to share betwen them (place ports/distfiles there). I newfs'ed it from -stable and wrote on it from -current. When I booted with -stable I've found the partition FS was broken. I think it's because of extended atributes -current wrote on it. I don't like to turn off extended attributes on -current at all. I'd like to have some option for mount to disable it (I've not found it on manpage). If you newfs'd the partition with -current, you made it UFS2. -stable can't mount UFS2 partitions. Newfs it with -stable (or the appropirate option on -current, I don't recall it) so its mountable on both systems. I'm making a broad assumption here since you haven't explained what FS was broken means. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: really 4.9 stability
On Sun, 21 Sep 2003, Ceri Davies wrote: I'm confused; how does one disable PAE? I don't see a kernel option for it. 'options PAE' turns it on. Without it turns it off. :) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -current brake ufs for -stable
On Sun, 21 Sep 2003, Doug White wrote: On Sun, 21 Sep 2003, Sergey Matveychuk wrote: I've installed both -current and -stable on my box. One of partition I plan to share betwen them (place ports/distfiles there). I newfs'ed it from -stable and wrote on it from -current. When I booted with -stable I've found the partition FS was broken. I think it's because of extended atributes -current wrote on it. I don't like to turn off extended attributes on -current at all. I'd like to have some option for mount to disable it (I've not found it on manpage). If you newfs'd the partition with -current, you made it UFS2. -stable can't mount UFS2 partitions. Newfs it with -stable (or the appropirate option on -current, I don't recall it) so its mountable on both systems. Actually, he did state that I newfs'ed it from -stable and wrote on it from -current ... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -current on laptop: panic: m_free detected a mbuf double free
OLDCARD doesn't work as well. Tried to get my Xircom REM56G-100 to run with OLDCARD but card won't be detected by pccardd. ifconfig -a only shows lp0 and lo0. Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt
Le 2003-09-21, Bryan Liesner écrivait : Thanks, the hang problems are fixed now. That's great news! No one told me that I was barking up the wrong tree... Ah, computers are fragile and playful things that always find creative and unexcepted ways of failing... :) Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
atapicam and dvd-r(w)
Hi, i still have problems with atapicam and atang, while booting with atapicam i get these messages: Sep 21 23:30:17 dreamland kernel: atapci0: Intel ICH4 UDMA100 controller port 0xf000-0xf00f,0-0x3,0-0x7,0-0x3,0-0x7 irq 10 at device 31.1 on pci0 Sep 21 23:30:17 dreamland kernel: ata0: at 0x1f0 irq 14 on atapci0 Sep 21 23:30:17 dreamland kernel: ata0: [MPSAFE] Sep 21 23:30:17 dreamland kernel: ata1: at 0x170 irq 15 on atapci0 Sep 21 23:30:17 dreamland kernel: ata1: [MPSAFE] ... Sep 21 23:03:58 dreamland kernel: GEOM: create disk ad0 dp=0xc5bda970 Sep 21 23:03:58 dreamland kernel: ad0: 78533MB IC35L080AVVA07-0 [159560/16/63] at ata0-master UDMA100 Sep 21 23:03:58 dreamland kernel: GEOM: create disk ad1 dp=0xc5bda870 Sep 21 23:03:58 dreamland kernel: ad1: 58644MB IC35L060AVVA07-0 [119150/16/63] at ata0-slave UDMA100 Sep 21 23:03:58 dreamland kernel: acd0: DVDR PIONEER DVD-RW DVR-106D at ata1-master UDMA33 Sep 21 23:03:58 dreamland kernel: Waiting 8 seconds for SCSI devices to settle (probe2:ata1:0:0:0): Recovered Sense (probe2:ata1:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe2:ata1:0:0:0): CAM Status: SCSI Status Error (probe2:ata1:0:0:0): SCSI Status: Check Condition (probe2:ata1:0:0:0): ILLEGAL REQUEST asc:24,0 (probe2:ata1:0:0:0): Invalid field in CDB: Command byte 1 bit 0 is invalid (probe2:ata1:0:0:0): Recovered Sense (probe2:ata1:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe2:ata1:0:0:0): CAM Status: SCSI Status Error (probe2:ata1:0:0:0): SCSI Status: Check Condition (probe2:ata1:0:0:0): ILLEGAL REQUEST asc:24,0 (probe2:ata1:0:0:0): Invalid field in CDB: Command byte 1 bit 0 is invalid Mounting root from ufs:/dev/ad0s2a (cd2:ata1:0:0:0): Recovered Sense (cd2:ata1:0:0:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd2:ata1:0:0:0): CAM Status: SCSI Status Error (cd2:ata1:0:0:0): SCSI Status: Check Condition (cd2:ata1:0:0:0): NOT READY asc:3a,0 (cd2:ata1:0:0:0): Medium not present Sep 21 23:03:58 dreamland kernel: cd2 at ata1 bus 0 target 0 lun 0 Sep 21 23:03:58 dreamland kernel: cd2: PIONEER DVD-RW DVR-106D 1.06 Removable CD-ROM SCSI-0 device Sep 21 23:03:58 dreamland kernel: cd2: 33.000MB/s transfers Sep 21 23:03:58 dreamland kernel: cd2: cd present [1 x 2048 byte records] Sep 21 23:03:58 dreamland kernel: Mounting root from ufs:/dev/ad0s2a Sep 21 23:03:58 dreamland kernel: cd0 at ahc0 bus 0 target 2 lun 0 Sep 21 23:03:58 dreamland kernel: cd0: PIONEER DVD-ROM DVD-303 1.10 Removable CD-ROM SCSI-2 device Sep 21 23:03:58 dreamland kernel: cd0: 20.000MB/s transfers (20.000MHz, offset 8) Sep 21 23:03:58 dreamland kernel: cd0: Attempt to query device size failed: NOT READY, Medium not present Sep 21 23:03:58 dreamland kernel: WARNING: / was not properly dismounted Sep 21 23:03:58 dreamland kernel: cd1 at ahc0 bus 0 target 3 lun 0 Sep 21 23:03:58 dreamland kernel: cd1: PLEXTOR CD-ROM PX-40TS 1.05 Removable CD-ROM SCSI-2 device Sep 21 23:03:58 dreamland kernel: cd1: 20.000MB/s transfers (20.000MHz, offset 15) Sep 21 23:03:58 dreamland kernel: cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed When trying to burn a disk with cdrecord i get the following panic: panic: mutex vm object not owned at /usr/src/sys/vm/vm_page.c:761 Is this related to the above failures or some issue with cdrecord? The kernel is current: FreeBSD dreamland.chief.home 5.1-CURRENT FreeBSD 5.1-CURRENT #6: Sun Sep 21 23:20:12 CEST 2003 I also have a backtrace of this but it seems to show nothing I could make any sense of: can not access 0xc04835a0, invalid address (c04835a0) can not access 0xc04835a0, invalid address (c04835a0) panic messages: --- dmesg: kvm_read: invalid address (c04de0bc) --- can not access 0xc048129c, invalid address (c048129c) can not access 0xc048129c, invalid address (c048129c) can not access 0xc04835e0, invalid address (c04835e0) can not access 0xc04835e0, invalid address (c04835e0) #0 0x in ?? () Regards, Sascha ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: X10 Wireless Technology Inc USB Receiver
On Sun, Sep 21, 2003 at 10:35:33AM -0700, Lars Eggert wrote:
Hi,
I'm trying to get the USB RF remote control that comes with some ATI
Wonder cards to do something meaningful under -current.
It shows up as an X10 Wireless Technology Inc USB Receiver with three
devices: /dev/ugen0, and the corresponding input (/dev/ugen0.1) and
output endpoints (/dev/ugen/0.2). Also see the attached usbctl output.
Simply reading from the input endpoint /dev/ugen0.1 doesn't work.
This page (http://remotew.free.fr/linux_en.htm) points at the Gatos
project, which has a Linux driver (ati_remote) that seems to make the
remote show up as a USB keyboard:
http://sourceforge.net/project/showfiles.php?group_id=12629
That driver sends a couple of magic bytes to the device during
initialization. I'm trying to do the same from userland:
static char init1[]= { 0x80, 0x01, 0x00, 0x20, 0x14 };
static char init2[]= { 0x80, 0x01, 0x00, 0x20, 0x14, 0x20, 0x20, 0x20 };
int main(int argc, char *argv[]) {
int out = open(/dev/ugen0.2, O_WRONLY);
if (out == -1) {
perror(ugen0.2);
goto done;
}
if (write(out, init1, sizeof init1) == -1) {
perror(write init1);
goto done;
}
if (write(out, init2, sizeof init2) == -1) {
perror(write init1);
goto done;
}
done:
close(out);
}
Really simply. Here's what happens when I run it:
write init1: Input/output error
Are you shure that the above is correct data for the device?
The IO error could also be returned from the device.
What does USB_DEBUG with hw.usb.debug=2 and hw.usb.ugen.debug=2 say?
Bevor I download the complete source you mentioned, can you give us the
lines that lead to the above command?
it feels like I'm missing something extremely obvious, but I'm new to
the USB internals. The two endpoints are interrupt endpoints. I'm not
sure what that signifies, but I heard writing to them on -stable is
broken, but on -current it should work.
I don't know, but it could also depend on the controller you use.
E.g. ehci currently doesn't support interrupt endpoints at all.
--
B.Walter BWCThttp://www.bwct.de
[EMAIL PROTECTED] [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: X10 Wireless Technology Inc USB Receiver
Bernd,
Bernd Walter wrote:
On Sun, Sep 21, 2003 at 10:35:33AM -0700, Lars Eggert wrote:
static char init1[]= { 0x80, 0x01, 0x00, 0x20, 0x14 };
static char init2[]= { 0x80, 0x01, 0x00, 0x20, 0x14, 0x20, 0x20, 0x20 };
Are you shure that the above is correct data for the device?
The IO error could also be returned from the device.
Relatively. It's in the Linux driver, and I've used a Windows USB
snooper to verify that ATI's Windows driver writes the same two chunks.
What does USB_DEBUG with hw.usb.debug=2 and hw.usb.ugen.debug=2 say?
Bevor I download the complete source you mentioned, can you give us the
lines that lead to the above command?
I'm away from that machine until later, I'll make sure to send the
output when I get back.
The Linux driver is actually pretty short. Here's the source:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gatos/ati_remote/ati_remote.c?annotate=1.9
The init packets get written at line 440.
I don't know, but it could also depend on the controller you use.
E.g. ehci currently doesn't support interrupt endpoints at all.
Ah. Yes, this is with ehci coupled to ohci. Should I try to disable ehci
for now?
Thanks,
Lars
--
Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute
smime.p7s
Description: S/MIME Cryptographic Signature
Re: X10 Wireless Technology Inc USB Receiver
On Sun, Sep 21, 2003 at 03:32:28PM -0700, Lars Eggert wrote:
Bernd,
Bernd Walter wrote:
On Sun, Sep 21, 2003 at 10:35:33AM -0700, Lars Eggert wrote:
static char init1[]= { 0x80, 0x01, 0x00, 0x20, 0x14 };
static char init2[]= { 0x80, 0x01, 0x00, 0x20, 0x14, 0x20, 0x20, 0x20 };
Are you shure that the above is correct data for the device?
The IO error could also be returned from the device.
Relatively. It's in the Linux driver, and I've used a Windows USB
snooper to verify that ATI's Windows driver writes the same two chunks.
What does USB_DEBUG with hw.usb.debug=2 and hw.usb.ugen.debug=2 say?
Bevor I download the complete source you mentioned, can you give us the
lines that lead to the above command?
I'm away from that machine until later, I'll make sure to send the
output when I get back.
The Linux driver is actually pretty short. Here's the source:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gatos/ati_remote/ati_remote.c?annotate=1.9
The init packets get written at line 440.
Mmm - looks you are right, but your init data seems to be different.
0x8001 vs 0x8003 and 0x8007.
Interesting is the calculation of transfer_buffer_length in
send_packet(), which would result in 4 for init1 and 8 for init2.
I interpret this that the last byte from init1 doesn't get written
and your packets don't fit into that sheme.
The source looks very confusing to me, but maybe that because of my
current localtime()...
The Windows log could help as it's at least readable and familar.
I don't know, but it could also depend on the controller you use.
E.g. ehci currently doesn't support interrupt endpoints at all.
Ah. Yes, this is with ehci coupled to ohci. Should I try to disable ehci
for now?
Unless it's a high speed device ohci takes care for it anyway,
but I doubt that a remote control device is high speed.
--
B.Walter BWCThttp://www.bwct.de
[EMAIL PROTECTED] [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng no good for me/REQUEST_SENSE recovered from missing interrupt
On Mon, 2003-09-22 at 00:07, Thomas Quinot wrote: Le 2003-09-21, Bryan Liesner écrivait : Thanks, the hang problems are fixed now. That's great news! I am also very grateful for your fix. I now seem to be able to run -CURRENT on my home desktop without any issues whatsoever :) No one told me that I was barking up the wrong tree... Ah, computers are fragile and playful things that always find creative and unexcepted ways of failing... :) Speaking of failing, should I completely disregard the probe2:ata1 warnings during boot which you saw in the dmesg output I sent you ? Sincerely, Dan Naumov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
On Mon, 2003-09-22 at 00:42, Daniel Eischen wrote: We've already been over this before. The problem is not as bad as you think, and there are other platforms that don't have -pthread. And those platforms would be? Sincerely, Dan Naumov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
atapicam error messages at boot/appears to work nonetheless
I'm getting complaints from ata or atapicam during boot-up, but my CD-ROM seems fine (reading, at least). ACPI enabled, sym driver enabled + in use with a 875 chip (Tekram DC-390F) and cd0, da0, sa0, sa1. Is this something to worry about? dmesg excerpt: ... atapci0: VIA 82C686A UDMA66 controller port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] ... Waiting 15 seconds for SCSI devices to settle (probe2:ata1:0:0:0): Recovered Sense (probe2:ata1:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe2:ata1:0:0:0): CAM Status: SCSI Status Error (probe2:ata1:0:0:0): SCSI Status: Check Condition (probe2:ata1:0:0:0): ILLEGAL REQUEST asc:24,0 (probe2:ata1:0:0:0): Invalid field in CDB (probe2:ata1:0:0:0): Recovered Sense (probe2:ata1:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe2:ata1:0:0:0): CAM Status: SCSI Status Error (probe2:ata1:0:0:0): SCSI Status: Check Condition (probe2:ata1:0:0:0): ILLEGAL REQUEST asc:24,0 (probe2:ata1:0:0:0): Invalid field in CDB ... cd1 at ata1 bus 0 target 0 lun 0 cd1: PLEXTOR CD-R PX-W4824A 1.05 Removable CD-ROM SCSI-0 device cd1: 33.000MB/s transfers cd1: cd present [216058 x 2048 byte records] ... cd9660: Joliet Extension (Level 1) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI and a Toshiba Tecra 8000
Nate Lawson wrote: On Wed, 17 Sep 2003, Andrew Thompson wrote: It has helped and the laptop is able to suspend with the serial cable attached (further than before). It now panics on the first resume with the following (gdb output at bottom). I think the serial cable is masking the problem as without it I can suspend/resume once and it only panics on the second resume. I guess I need the serail working to see that panic anyway. You should do a quick grep through sys/dev/syscons for = sc-cur_scp-index and replace them all with the above NULL check. I'm interested if this will fix things. Hi, I fixed the other null derefernce in sc_bell() and the laptop is now suspending with the serial console the same as without. Here is the output when I suspend the laptop (S3). After the first resume the laptop still works fine. When I suspend the laptop a second time no output is displayed but the laptop seems to suspend alright (according to the power led), but when it resumes it reboots straight away. Again no output on the serial. Is there more debugging that I can turn on? suspend #1 acpi_printcpu() debug dump gdt[0077:c04b8ce0] idt[0407:c04b9080] ldt[0028] tr[0020] efl[0096] eax[1000] ebx[c1234d00] ecx[] edx[bfc4] esi[] edi[c09f53b0] ebp[c62ffaa8] esp[c62ffa70] cr0[8005003b] cr2[280b0b40] cr3[0205b000] cr4[0091] cs[0008] ds[0010] es[0010] fs[0018] gs[002f] ss[0010] resume #1 acpi_printcpu() debug dump gdt[0077:c04b8ce0] idt[0407:c04b9080] ldt[0028] tr[0020] efl[0002] eax[0001] ebx[c1234d00] ecx[8000] edx[c1286980] esi[] edi[c09f53b0] ebp[c62ffaa8] esp[c62ffa70] cr0[8005003b] cr2[280b0b40] cr3[0205b000] cr4[0091] cs[0008] ds[0010] es[0010] fs[0018] gs[002f] ss[0010] pcib0: slot 4 INTA is routed to irq 11 pcib0: slot 5 INTD is routed to irq 11 pcib0: slot 9 INTA is routed to irq 11 pcib0: slot 11 INTA is routed to irq 11 pcib0: slot 11 INTB is routed to irq 11 wakeup from sleeping state (slept 00:00:27) ata0: resetting devices .. acpi_acad0: Notify 0x80 done ata1: resetting devices .. done acpi_cmbat0: battery initialization start acpi_cmbat0: battery initialization done, tried 1 times acpi_cmbat1: battery initialization start acpi_cmbat1: battery initialization failed, giving up suspend #2 (no output) resume #2 (no output and reboot) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -current brake ufs for -stable
On Sun, 21 Sep 2003, Marc G. Fournier wrote: On Sun, 21 Sep 2003, Doug White wrote: On Sun, 21 Sep 2003, Sergey Matveychuk wrote: I've installed both -current and -stable on my box. One of partition I plan to share betwen them (place ports/distfiles there). I newfs'ed it from -stable and wrote on it from -current. When I booted with -stable I've found the partition FS was broken. I think it's because of extended atributes -current wrote on it. I don't like to turn off extended attributes on -current at all. I'd like to have some option for mount to disable it (I've not found it on manpage). -current doesn't write extended attributes unless you enabled them. Most likely the problem is some breakage of compatibility of superblocks. When I tried sharing a filesystem between RELENG_3 and -current a few months ago, IIRC the obvious bugs were that RELENG_3 crashed on filesystems written to be -current, and running RELENG_3's fdisk fixed the problem but was not run automatically and it reported an alarming number of errors. It should be run automatically, e.g., by using a different dirty flag for each variant -- set all dirty flags on write and only clear the dirty flag for the current variant on unmount. If you newfs'd the partition with -current, you made it UFS2. -stable can't mount UFS2 partitions. Newfs it with -stable (or the appropirate option on -current, I don't recall it) so its mountable on both systems. Actually, he did state that I newfs'ed it from -stable and wrote on it from -current ... Anyway, -current doesn't imply UFS2. UFS2 is just the default. I only use it for running benchmarks to determine whether I should use it yet. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: X10 Wireless Technology Inc USB Receiver
On Sun, 21 Sep 2003, Lars Eggert wrote: I'm trying to get the USB RF remote control that comes with some ATI Wonder cards to do something meaningful under -current. Can I recommend the use of libusb for the abstracting of the USB layer? It would allow your driver/interface to work on all FreeBSD, Linux and Solaris. I've found the graphics/s10sh port to be really useful as an example of libusb's usage... Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: X10 Wireless Technology Inc USB Receiver
Bernd, Bernd Walter wrote: What does USB_DEBUG with hw.usb.debug=2 and hw.usb.ugen.debug=2 say? it says this: usbd_setup_pipe: dev=0xc3f9d980 iface=0xc3efbaa0 ep=0xc3f192c8 pipe=0xdb936974 ugenwrite: transfer 5 bytes usbd_intr_transfer: start transfer 5 bytes usbd_intr_transfer: transferred 0 usbd_intr_transfer: error=13 (This is with ehci disabled.) Mmm - looks you are right, but your init data seems to be different. 0x8001 vs 0x8003 and 0x8007. I think the only difference is that I prepended the 0x80 directly, which the Linux driver fudges in front in send_packet. Interesting is the calculation of transfer_buffer_length in send_packet(), which would result in 4 for init1 and 8 for init2. I interpret this that the last byte from init1 doesn't get written and your packets don't fit into that sheme. I think they do, see the Windows dump. The source looks very confusing to me, but maybe that because of my current localtime()... No, it's not :-) After I reading that driver, I know why I like the BSD sources. The Windows log could help as it's at least readable and familar. It's attached, in whatever format snoopy (http://sourceforge.net/projects/usbsnoop/) saves it. It shows two writes with this data: TransferBuffer: 0x0005 (5) length : 80 01 00 20 14 TransferBuffer: 0x0008 (8) length : 80 01 00 20 14 20 20 20 Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute USBLog1.usblog Description: Binary data smime.p7s Description: S/MIME Cryptographic Signature
No/weird mixer in -CURRENT
I just set up a new box with -CURRENT on it, using 20030918-JPSNAP (cvsup'ed the next day), and I'm having some really strange things going on with volume control. aumix won't complain, and will successfully query the mixer device. I can set the volume levels to my hearts content, but the only thing that actually works is if I set the PCM volume to 0 -- which mutes everything. Any other setting, on any other channel, leaves the volume at full. I thought this was weird, but before posting, I tested with gkrellm. Using the volume plugin for gkrellm2, it tells me that /dev/mixer0 is not a valid mixer device. So I went through /dev/audio*, /dev/dsp*, /dev/sequencer*, but none of them worked (which didn't surprise me, as they're not mixer devices). I've noticed that /dev/mixer doesn't exist, though the patterns of other devices lead me to believe that it should be a symlink to /dev/mixer0, which /does/ exist. This is a fairly new machine, using a DFI PS83-BL motherboard. pcm0 is picked up as an Intel ICH5 (82801EB), and a C-Media Electronics CMI9739 AC97 Codec. Does pcm not fully understand my audio device, am I lacking a mixer, or is it something else entirely? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
On Mon, 22 Sep 2003, Dan Naumov wrote: On Mon, 2003-09-22 at 00:42, Daniel Eischen wrote: We've already been over this before. The problem is not as bad as you think, and there are other platforms that don't have -pthread. And those platforms would be? Solaris for one: bash-2.05$ uname -a SunOS pcnet5 5.8 Generic_108528-12 sun4u sparc SUNW,Ultra-2 bash-2.05$ type cc cc is hashed (/usr/ucb/cc) bash-2.05$ type gcc gcc is hashed (/usr/local/bin/gcc) bash-2.05$ cc -pthread cc: unrecognized option `-pthread' cc: No input files bash-2.05$ gcc -pthread gcc: unrecognized option `-pthread' gcc: No input files gcc does have -pthreads and -threads for Solaris, but these are basically NOOPs (just what we are doing). They define -D_REENTRANT -D_PTHREADS for -pthreads and -D_REENTRANT and -D_SOLARIS_THREADS for -threads. These do not specify any libraries to link, just predefines. FreeBSD doesn't have anything to predefine, so it is a true NOOP. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
On Sun, 21 Sep 2003, Daniel Eischen wrote: On Mon, 22 Sep 2003, Dan Naumov wrote: On Mon, 2003-09-22 at 00:42, Daniel Eischen wrote: We've already been over this before. The problem is not as bad as you think, and there are other platforms that don't have -pthread. And those platforms would be? Solaris for one: bash-2.05$ uname -a SunOS pcnet5 5.8 Generic_108528-12 sun4u sparc SUNW,Ultra-2 bash-2.05$ type cc cc is hashed (/usr/ucb/cc) bash-2.05$ type gcc gcc is hashed (/usr/local/bin/gcc) bash-2.05$ cc -pthread cc: unrecognized option `-pthread' cc: No input files bash-2.05$ gcc -pthread gcc: unrecognized option `-pthread' gcc: No input files gcc does have -pthreads and -threads for Solaris, but these are basically NOOPs (just what we are doing). They define -D_REENTRANT -D_PTHREADS for -pthreads and -D_REENTRANT and -D_SOLARIS_THREADS for -threads. These do not specify any libraries to link, just predefines. FreeBSD doesn't have anything to predefine, so it is a true NOOP. Actually, it does look like the Solaris -threads and -pthreads options do imply linking to -lthread and -lpthread respectively (when not building with -shared). But regardless, -threads and -pthreads are not portable. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
g_up panic, finally with stack trace!
This is 10days old kernel panic, the same type I report before, but now I use dont-sync-on-panic sysctl, so some stack trace finally available: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc017fdab stack pointer = 0x10:0xcd36bb04 frame pointer = 0x10:0xcd36bb18 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 3 (g_up) trap number = 12 panic: page fault #0 0xc018a4bb in doadump () #1 0xc018ab44 in boot () #2 0xc018aee8 in panic () #3 0xc02992dc in trap_fatal () #4 0xc0298983 in trap () #5 0xc02897d8 in calltrap () #6 0xc01801f9 in _mtx_lock_sleep () #7 0xc01d3fac in bufdone () #8 0xc01d7e78 in cluster_callback () #9 0xc01d3f11 in bufdone () #10 0xc01d3d8e in bufdonebio () #11 0xc01d3b5c in biodone () #12 0xc01520ba in g_dev_done () #13 0xc01d3b5c in biodone () #14 0xc0154d28 in g_io_schedule_up () #15 0xc0154f38 in g_up_procbody () #16 0xc0173b51 in fork_exit () ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
Doug Barton wrote: On Sun, 21 Sep 2003, John Birrell wrote: On Sun, Sep 21, 2003 at 01:25:09AM -0700, Doug Barton wrote: I am a little confused about one thing though. What is going to happen to third party apps that use -pthread that aren't compiled through the ports? They need to replace -pthread with their thread library of choice (e.g. -lc_r or -lpthread). E... I'm not sure this is an optimal solution. There is an awful lot of software out there which expects -pthread to just work. Wouldn't it make more sense to default it to one thing or the other, then make it configurable (isn't this what libmap.conf is supposed to help with)? Doug I have to agree with this. '-pthread' seems to have taken on the meaning of 'turn on whatever magic makes the pthreads library work'. The application writer is allowed to focus on the application, not the FreeBSD-specific threading library options. The user is allowed to compile a third-party app without having to worry about the FreeBSD-specific threading library options. Everyone wins. If we take the stand that any software that uses '-pthread' is broken and should be fixed by the author, it will make FreeBSD wildly unpopular. If we take the stand that the only sactioned way to compile a third-party app in FreeBSD is via the ports system, then FreeBSD will become much less usable. I've tried to stay silent on this issue in hopes that it would work itself out, but I'm not quite sure that it is. Making FreeBSD harder to use and harder to program for in the name of pendanticy is not the best direction. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
