Re: HEADS UP! 6.0-RELEASE coming
On Mon, Oct 31, 2005 at 05:01:50PM +0100, Marc Olzheim wrote: Is the 'VM/VFS overruns' item still a problem? That was likely fixed a couple of months ago. If not then it's definitely something that I'll track for the 6.1 release. I'll retest that one, but it wasn't fixed yet in -CURRENT of a month ago. I'm happy to confirm that it works fine now in today's RELENG_6. :-) Marc pgpFWi34CteRC.pgp Description: PGP signature
Re: HEADS UP! 6.0-RELEASE coming
On Tue, Nov 01, 2005 at 06:40:42AM +0600, Max Khon wrote: Linking against -lthr (or even -lc_r!) instead of -lpthread solves gdb The program no longer exists. problem for me on RELENG_6. Well, yes, but that's not the same. While running on M:N KSE, all sorts of locking needs to be correct, which with non M:N threading you can get away with some (intentional or not) sloppiness. So debugging a fully threaded program with a non M:N threadlib is not always useful. Marc pgpcUoe0kHN70.pgp Description: PGP signature
Re: HEADS UP! 6.0-RELEASE coming
Hi! On Tue, Nov 01, 2005 at 12:29:00PM +0100, Marc Olzheim wrote: Linking against -lthr (or even -lc_r!) instead of -lpthread solves gdb The program no longer exists. problem for me on RELENG_6. Well, yes, but that's not the same. While running on M:N KSE, all sorts of locking needs to be correct, which with non M:N threading you can get away with some (intentional or not) sloppiness. So debugging a fully threaded program with a non M:N threadlib is not always useful. I do not think that maintaining M:N thread lib is feasible, given the lack of resources. Solaris has already moved from M:N to 1:1. Linux (NPTL) is 1:1 as well. /fjoe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
On Tue, Nov 01, 2005 at 06:33:21PM +0600, Max Khon wrote: Hi! On Tue, Nov 01, 2005 at 12:29:00PM +0100, Marc Olzheim wrote: Linking against -lthr (or even -lc_r!) instead of -lpthread solves gdb The program no longer exists. problem for me on RELENG_6. Well, yes, but that's not the same. While running on M:N KSE, all sorts of locking needs to be correct, which with non M:N threading you can get away with some (intentional or not) sloppiness. So debugging a fully threaded program with a non M:N threadlib is not always useful. I do not think that maintaining M:N thread lib is feasible, given the lack of resources. Solaris has already moved from M:N to 1:1. Linux (NPTL) is 1:1 as well. Well, each threading system has it's own application. Having an easy way to have one multithreaded process use multiple CPUs is a big win in any case. Especially in computationally intensive tasks... Marc pgpYL0KsZKoAU.pgp Description: PGP signature
Re: HEADS UP! 6.0-RELEASE coming
Marc Olzheim wrote: On Tue, Nov 01, 2005 at 06:33:21PM +0600, Max Khon wrote: Hi! On Tue, Nov 01, 2005 at 12:29:00PM +0100, Marc Olzheim wrote: Linking against -lthr (or even -lc_r!) instead of -lpthread solves gdb The program no longer exists. problem for me on RELENG_6. Well, yes, but that's not the same. While running on M:N KSE, all sorts of locking needs to be correct, which with non M:N threading you can get away with some (intentional or not) sloppiness. So debugging a fully threaded program with a non M:N threadlib is not always useful. I do not think that maintaining M:N thread lib is feasible, given the lack of resources. Solaris has already moved from M:N to 1:1. Linux (NPTL) is 1:1 as well. Well, each threading system has it's own application. Having an easy way to have one multithreaded process use multiple CPUs is a big win in any case. Especially in computationally intensive tasks... Marc There is little difference between 1:1 and M:N from the application's point of view. Both will allow multiple application threads to run concurrently on multiple CPUs, and both will allow other process threads to run when the current thread blocks in the kernel. The difference is in the details with how they are scheduled and what kernel resources they use. 1:1 has the advantage of being much less complex to implement and maintain, while M:N has the theoretical advantage of cheaper thread context switches. That theory hasn't panned out, though, due to synchronization requirements and the technical requirements of proper TLS support. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
On Tue, 1 Nov 2005, Scott Long wrote: There is little difference between 1:1 and M:N from the application's point of view. Both will allow multiple application threads to run concurrently on multiple CPUs, and both will allow other process threads to run when the current thread blocks in the kernel. The difference is in the details with how they are scheduled and what kernel resources they use. 1:1 has the advantage of being much less complex to implement and maintain, while M:N has the theoretical advantage of cheaper thread context switches. That theory hasn't panned out, though, due to synchronization requirements and the technical requirements of proper TLS support. I've observed at least one situation in which m:n threading has performed significantly better as a result of better use of CPU resources. Specifically, it appears (on face value) as though libpthread is avoiding over-contention of resources by limiting the number of threads entering the kernel in contentious situations on SMP. I've not yet had the opportunity to confirm this outside of micro-benchmark environments, and plan to do so in the next few weeks. This doesn't mean that this is impossible to do with libthr, just that we may need some more scheduler investigation to make libthr catch up on SMP in that environment. Details to follow as available. Robert N M Watson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
On Thu, Oct 27, 2005 at 12:05:07PM -0600, Scott Long wrote: Everyone is still welcome to update their sources on the RELENG_6_0 branch and provide feedback for the next 48 hours or so. The release will likely be announced by the end of the weekend or early next week, at the latest. Anyone having updates for my showstopper page, please, notify me... http://www.stack.nl/%7Emarcolz/FreeBSD/showstoppers.html We are still installing new servers with 4.x, because I haven't seen a really stable FreeBSD-stable release since... This includes current RELENG_6_0. Marc pgpwBkYMoH4WF.pgp Description: PGP signature
Re: HEADS UP! 6.0-RELEASE coming
Marc Olzheim wrote: On Thu, Oct 27, 2005 at 12:05:07PM -0600, Scott Long wrote: Everyone is still welcome to update their sources on the RELENG_6_0 branch and provide feedback for the next 48 hours or so. The release will likely be announced by the end of the weekend or early next week, at the latest. Anyone having updates for my showstopper page, please, notify me... http://www.stack.nl/%7Emarcolz/FreeBSD/showstoppers.html We are still installing new servers with 4.x, because I haven't seen a really stable FreeBSD-stable release since... This includes current RELENG_6_0. Marc The pty problem is likely a side effect of known locking problems with ttys and ptys in general. This probably the weakest part of the kernel right now and I don't know of a good work-around for apps that use these extensively. That said, there doesn't seem to be much of a problem with casual use; I use screen(1) quite a bit on my production 6.0-RC mailserver+firewall. Is the 'VM/VFS overruns' item still a problem? That was likely fixed a couple of months ago. If not then it's definitely something that I'll track for the 6.1 release. The ACPI+sio problem is known. I have a motherboard with a similar problem, though a different brand than yours. I solved it by removing the ACPI attachment from the sio code. The better solution is to allow loader hints to override ACPI hints. I tried talking to John Baldwin about this but didn't get much of a response. I haven't seen ktrace discussed much. Peter Edwards is welcome to pass his patch around some more and commit it if he wants. GDB problems are numerous, and what we really need is for someone with interest in it to spend some quality time on it. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
On Mon, Oct 31, 2005 at 08:36:42AM -0700, Scott Long wrote: Anyone having updates for my showstopper page, please, notify me... http://www.stack.nl/%7Emarcolz/FreeBSD/showstoppers.html The pty problem is likely a side effect of known locking problems with ttys and ptys in general. This probably the weakest part of the kernel right now and I don't know of a good work-around for apps that use these extensively. That said, there doesn't seem to be much of a problem with casual use; I use screen(1) quite a bit on my production 6.0-RC mailserver+firewall. I know it doesn't trigger too often for most users, but still, for us, once a week per server on 2 production servers we installed FreeBSD 5 and 6 on, is way too often. :-( More so because these kernel panics on SMP systems tend to utterly destroy soft-updates consistency giving fsck quite a workout and resulting in data loss... Is the 'VM/VFS overruns' item still a problem? That was likely fixed a couple of months ago. If not then it's definitely something that I'll track for the 6.1 release. I'll retest that one, but it wasn't fixed yet in -CURRENT of a month ago. The ACPI+sio problem is known. I have a motherboard with a similar problem, though a different brand than yours. I solved it by removing the ACPI attachment from the sio code. The better solution is to allow loader hints to override ACPI hints. I tried talking to John Baldwin about this but didn't get much of a response. I've tried all suggestions so far, but to no avail on most servers. Too many broken ACPI implementations I fear... Too bad motherboard vendors don't take the time to push proper software in their flash. In any case, thanks for thinking along with me. :-) Marc pgpJ8foTNWCdW.pgp Description: PGP signature
Re: HEADS UP! 6.0-RELEASE coming
The ACPI+sio problem is known. I have a motherboard with a similar problem, though a different brand than yours. I solved it by removing the ACPI attachment from the sio code. The better solution is to allow loader hints to override ACPI hints. I tried talking to John Baldwin about this but didn't get much of a response. I've tried all suggestions so far, but to no avail on most servers. Too many broken ACPI implementations I fear... Too bad motherboard vendors don't take the time to push proper software in their flash. Right now acpi tells us there's a device, and we use it. Loader hints should be used to map locations to device instances. It is more general than just ACPI, however. People want to bind sio to a specific port that comes out the back. People also want to bind rl0 to the card in slot 3. Consider my system: sio0 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.SBRG.UAR1 sio1 pnpinfo _HID=PNP0501 _UID=2 at handle=\_SB_.PCI0.SBRG.UAR2 On this system, UAR1 is the port that comes out the back, so I have what I want. However, I'd like to be able to say: hint.sio.0.at=acpi hint.sio.0.location=\_SB_.PCI0.SBRG.UAR2 or hint.sio.0.at=acpi hint.sio.0.location=UAR2 or hint.fxp.0.at=pci hint.fxp.0.location=bus=2 slot=3 function=0 hint.fxp.1.at=pci hint.fxp.1.location=pci2:2:0 Since we really want to map the devices in some arbitrary ACPI tree to instances in the system, rather than mapping devices that happen to live at a specific resource address to specific instances in the tree. However, there are a number of issues in doing this generically and with error cases. How does one deal with the different syntaxes? What extensions to the newbus system are there? etc. Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
Warner Losh wrote: The ACPI+sio problem is known. I have a motherboard with a similar problem, though a different brand than yours. I solved it by removing the ACPI attachment from the sio code. The better solution is to allow loader hints to override ACPI hints. I tried talking to John Baldwin about this but didn't get much of a response. I've tried all suggestions so far, but to no avail on most servers. Too many broken ACPI implementations I fear... Too bad motherboard vendors don't take the time to push proper software in their flash. Right now acpi tells us there's a device, and we use it. Loader hints should be used to map locations to device instances. It is more general than just ACPI, however. People want to bind sio to a specific port that comes out the back. People also want to bind rl0 to the card in slot 3. Consider my system: sio0 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.SBRG.UAR1 sio1 pnpinfo _HID=PNP0501 _UID=2 at handle=\_SB_.PCI0.SBRG.UAR2 On this system, UAR1 is the port that comes out the back, so I have what I want. However, I'd like to be able to say: hint.sio.0.at=acpi hint.sio.0.location=\_SB_.PCI0.SBRG.UAR2 or hint.sio.0.at=acpi hint.sio.0.location=UAR2 or hint.fxp.0.at=pci hint.fxp.0.location=bus=2 slot=3 function=0 hint.fxp.1.at=pci hint.fxp.1.location=pci2:2:0 Since we really want to map the devices in some arbitrary ACPI tree to instances in the system, rather than mapping devices that happen to live at a specific resource address to specific instances in the tree. However, there are a number of issues in doing this generically and with error cases. How does one deal with the different syntaxes? What extensions to the newbus system are there? etc. Warner Well, in my case at least, what ACPI says about the sio resources is simply wrong, and I'm not smart enough to figure out how to correct the ASL or get it loaded correctly on boot. It would be easier if the sio-acpi attachment honored the hints that already exist for the purpose of describing the sio resources. Last I checked, neither Windows nor Linux nor Solaris required users to read the ACPI 2.0 spec to get their comms ports working. Having the flexibility to do what you describe above would be nice, but allowing mortal users to get their hardware working would be ever nicer. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
From: Scott Long [EMAIL PROTECTED] Subject: Re: HEADS UP! 6.0-RELEASE coming Date: Mon, 31 Oct 2005 10:42:32 -0700 Warner Losh wrote: The ACPI+sio problem is known. I have a motherboard with a similar problem, though a different brand than yours. I solved it by removing the ACPI attachment from the sio code. The better solution is to allow loader hints to override ACPI hints. I tried talking to John Baldwin about this but didn't get much of a response. I've tried all suggestions so far, but to no avail on most servers. Too many broken ACPI implementations I fear... Too bad motherboard vendors don't take the time to push proper software in their flash. Right now acpi tells us there's a device, and we use it. Loader hints should be used to map locations to device instances. It is more general than just ACPI, however. People want to bind sio to a specific port that comes out the back. People also want to bind rl0 to the card in slot 3. Consider my system: sio0 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.SBRG.UAR1 sio1 pnpinfo _HID=PNP0501 _UID=2 at handle=\_SB_.PCI0.SBRG.UAR2 On this system, UAR1 is the port that comes out the back, so I have what I want. However, I'd like to be able to say: hint.sio.0.at=acpi hint.sio.0.location=\_SB_.PCI0.SBRG.UAR2 or hint.sio.0.at=acpi hint.sio.0.location=UAR2 or hint.fxp.0.at=pci hint.fxp.0.location=bus=2 slot=3 function=0 hint.fxp.1.at=pci hint.fxp.1.location=pci2:2:0 Since we really want to map the devices in some arbitrary ACPI tree to instances in the system, rather than mapping devices that happen to live at a specific resource address to specific instances in the tree. However, there are a number of issues in doing this generically and with error cases. How does one deal with the different syntaxes? What extensions to the newbus system are there? etc. Warner Well, in my case at least, what ACPI says about the sio resources is simply wrong, and I'm not smart enough to figure out how to correct the ASL or get it loaded correctly on boot. It would be easier if the sio-acpi attachment honored the hints that already exist for the purpose of describing the sio resources. Last I checked, neither Windows nor Linux nor Solaris required users to read the ACPI 2.0 spec to get their comms ports working. Having the flexibility to do what you describe above would be nice, but allowing mortal users to get their hardware working would be ever nicer. I didn't need to read the AML to get the serial ports working in the above example. devinfo -v gave me all I needed to know, a command that's very accessible to mere mortals, as you put it. The issue with other boards that I've seen is that you have things like PORTA and PORTB which are listed in COM2 and then COM1 resource order. I could have sworn that the AML that you'd posted a while ago was a mirror of this. I'd be happy to take a look at the AML of the system you are having trouble with to confirm this. There is a secondary issue to this as well. That is that some com ports can be assigned to one of many different addresses. That also needs to be addressed, but so far appears to be fairly uncommon. Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
Marc Olzheim wrote: On Mon, Oct 31, 2005 at 08:36:42AM -0700, Scott Long wrote: Anyone having updates for my showstopper page, please, notify me... http://www.stack.nl/%7Emarcolz/FreeBSD/showstoppers.html The pty problem is likely a side effect of known locking problems with ttys and ptys in general. This probably the weakest part of the kernel right now and I don't know of a good work-around for apps that use these extensively. That said, there doesn't seem to be much of a problem with casual use; I use screen(1) quite a bit on my production 6.0-RC mailserver+firewall. I know it doesn't trigger too often for most users, but still, for us, once a week per server on 2 production servers we installed FreeBSD 5 and 6 on, is way too often. :-( for information, we have the same problem on our productions servers with FreeBSD 5 and I know that we are not alone. We hoped a lot for a solution with FreeBSD 6 after this thread : http://lists.freebsd.org/mailman/htdig/freebsd-stable/2005-June/016154.html but I have just tested with FreeBSD 6.0-RC1 and the problem is always there :-( -- Philippe PEGON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
On Mon, 31 Oct 2005, Warner Losh wrote: From: Scott Long [EMAIL PROTECTED] Subject: Re: HEADS UP! 6.0-RELEASE coming Date: Mon, 31 Oct 2005 10:42:32 -0700 Warner Losh wrote: The ACPI+sio problem is known. I have a motherboard with a similar problem, though a different brand than yours. I solved it by removing the ACPI attachment from the sio code. The better solution is to allow loader hints to override ACPI hints. I tried talking to John Baldwin about this but didn't get much of a response. I've tried all suggestions so far, but to no avail on most servers. Too many broken ACPI implementations I fear... Too bad motherboard vendors don't take the time to push proper software in their flash. Right now acpi tells us there's a device, and we use it. Loader hints should be used to map locations to device instances. It is more general than just ACPI, however. People want to bind sio to a specific port that comes out the back. People also want to bind rl0 to the card in slot 3. Consider my system: sio0 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.SBRG.UAR1 sio1 pnpinfo _HID=PNP0501 _UID=2 at handle=\_SB_.PCI0.SBRG.UAR2 On this system, UAR1 is the port that comes out the back, so I have what I want. However, I'd like to be able to say: hint.sio.0.at=acpi hint.sio.0.location=\_SB_.PCI0.SBRG.UAR2 or hint.sio.0.at=acpi hint.sio.0.location=UAR2 or hint.fxp.0.at=pci hint.fxp.0.location=bus=2 slot=3 function=0 hint.fxp.1.at=pci hint.fxp.1.location=pci2:2:0 Since we really want to map the devices in some arbitrary ACPI tree to instances in the system, rather than mapping devices that happen to live at a specific resource address to specific instances in the tree. However, there are a number of issues in doing this generically and with error cases. How does one deal with the different syntaxes? What extensions to the newbus system are there? etc. Warner Well, in my case at least, what ACPI says about the sio resources is simply wrong, and I'm not smart enough to figure out how to correct the ASL or get it loaded correctly on boot. It would be easier if the sio-acpi attachment honored the hints that already exist for the purpose of describing the sio resources. Last I checked, neither Windows nor Linux nor Solaris required users to read the ACPI 2.0 spec to get their comms ports working. Having the flexibility to do what you describe above would be nice, but allowing mortal users to get their hardware working would be ever nicer. I didn't need to read the AML to get the serial ports working in the above example. devinfo -v gave me all I needed to know, a command that's very accessible to mere mortals, as you put it. The issue with other boards that I've seen is that you have things like PORTA and PORTB which are listed in COM2 and then COM1 resource order. I could have sworn that the AML that you'd posted a while ago was a mirror of this. I'd be happy to take a look at the AML of the system you are having trouble with to confirm this. There is a secondary issue to this as well. That is that some com ports can be assigned to one of many different addresses. That also needs to be addressed, but so far appears to be fairly uncommon. Warner I guess I'm missing the jump between running devinfo and knowing how to parse and manipulate ASL/AML. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
From: Scott [EMAIL PROTECTED] Subject: Re: HEADS UP! 6.0-RELEASE coming Date: Mon, 31 Oct 2005 12:48:49 -0700 (MST) On Mon, 31 Oct 2005, Warner Losh wrote: From: Scott Long [EMAIL PROTECTED] Subject: Re: HEADS UP! 6.0-RELEASE coming Date: Mon, 31 Oct 2005 10:42:32 -0700 Warner Losh wrote: The ACPI+sio problem is known. I have a motherboard with a similar problem, though a different brand than yours. I solved it by removing the ACPI attachment from the sio code. The better solution is to allow loader hints to override ACPI hints. I tried talking to John Baldwin about this but didn't get much of a response. I've tried all suggestions so far, but to no avail on most servers. Too many broken ACPI implementations I fear... Too bad motherboard vendors don't take the time to push proper software in their flash. Right now acpi tells us there's a device, and we use it. Loader hints should be used to map locations to device instances. It is more general than just ACPI, however. People want to bind sio to a specific port that comes out the back. People also want to bind rl0 to the card in slot 3. Consider my system: sio0 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.SBRG.UAR1 sio1 pnpinfo _HID=PNP0501 _UID=2 at handle=\_SB_.PCI0.SBRG.UAR2 On this system, UAR1 is the port that comes out the back, so I have what I want. However, I'd like to be able to say: hint.sio.0.at=acpi hint.sio.0.location=\_SB_.PCI0.SBRG.UAR2 or hint.sio.0.at=acpi hint.sio.0.location=UAR2 or hint.fxp.0.at=pci hint.fxp.0.location=bus=2 slot=3 function=0 hint.fxp.1.at=pci hint.fxp.1.location=pci2:2:0 Since we really want to map the devices in some arbitrary ACPI tree to instances in the system, rather than mapping devices that happen to live at a specific resource address to specific instances in the tree. However, there are a number of issues in doing this generically and with error cases. How does one deal with the different syntaxes? What extensions to the newbus system are there? etc. Warner Well, in my case at least, what ACPI says about the sio resources is simply wrong, and I'm not smart enough to figure out how to correct the ASL or get it loaded correctly on boot. It would be easier if the sio-acpi attachment honored the hints that already exist for the purpose of describing the sio resources. Last I checked, neither Windows nor Linux nor Solaris required users to read the ACPI 2.0 spec to get their comms ports working. Having the flexibility to do what you describe above would be nice, but allowing mortal users to get their hardware working would be ever nicer. I didn't need to read the AML to get the serial ports working in the above example. devinfo -v gave me all I needed to know, a command that's very accessible to mere mortals, as you put it. The issue with other boards that I've seen is that you have things like PORTA and PORTB which are listed in COM2 and then COM1 resource order. I could have sworn that the AML that you'd posted a while ago was a mirror of this. I'd be happy to take a look at the AML of the system you are having trouble with to confirm this. There is a secondary issue to this as well. That is that some com ports can be assigned to one of many different addresses. That also needs to be addressed, but so far appears to be fairly uncommon. Warner I guess I'm missing the jump between running devinfo and knowing how to parse and manipulate ASL/AML. You'd indicated that you'd prefer a method of specification that didn't require one understand ASL. With devinfo, one can get all the information one needs to create the location hints that I describe above w/o needing to know ASL, look at ASL, etc. Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
On Mon, 31 Oct 2005, Marc Olzheim wrote: On Thu, Oct 27, 2005 at 12:05:07PM -0600, Scott Long wrote: Everyone is still welcome to update their sources on the RELENG_6_0 branch and provide feedback for the next 48 hours or so. The release will likely be announced by the end of the weekend or early next week, at the latest. Anyone having updates for my showstopper page, please, notify me... http://www.stack.nl/%7Emarcolz/FreeBSD/showstoppers.html We are still installing new servers with 4.x, because I haven't seen a really stable FreeBSD-stable release since... This includes current RELENG_6_0. I started going through the ktrace code a few days ago to look at adding thread IDs to ktrace records. I'm happy to pick up the ktrace item in your todo list. My plan is basically to restore elements of the 4.x queueing model: rather than asynchronously dispatching all ktrace records to a single worker thread, dispatch them to disk from the system call return path for a thread. There are a few issues with threading that require attention -- in particular, avoiding writes on the vnode operation after close. This will also slow down ktracing again, but should avoid dropping records. I hope to have something hacked together in a few days, but not in time for 6.0. Robert N M Watson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
Hi! On Mon, Oct 31, 2005 at 04:18:09PM +0100, Marc Olzheim wrote: Everyone is still welcome to update their sources on the RELENG_6_0 branch and provide feedback for the next 48 hours or so. The release will likely be announced by the end of the weekend or early next week, at the latest. Anyone having updates for my showstopper page, please, notify me... http://www.stack.nl/%7Emarcolz/FreeBSD/showstoppers.html We are still installing new servers with 4.x, because I haven't seen a really stable FreeBSD-stable release since... This includes current RELENG_6_0. Linking against -lthr (or even -lc_r!) instead of -lpthread solves gdb The program no longer exists. problem for me on RELENG_6. /fjoe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
On 10/30/05, Bryan Fullerton [EMAIL PROTECTED] wrote: I have raised this issue in the past, but no one responded. Did you submit a PR? Bryan No I didn't. There was no response so I figured maybe I was the only one affected. Jiawei -- Without the userland, the kernel is useless. --inspired by The Tao of Programming ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
On 10/29/05, Jung-uk Kim [EMAIL PROTECTED] wrote: Was that working X11 X.Org or XFree86? Older releases contains XFree86 and 6.0 contains X.Org. You can find both as a FreeBSD port under x11-servers category. Give XFree86 a try, maybe it is better for You. Or xorg-server-snap, maybe... Jung-uk Kim The problem is in sis.ko. Delete this file (disabling dri/drm only in xorg.conf is not useful), and Xorg will work again. I have raised this issue in the past, but no one responded. Jiawei -- Without the userland, the kernel is useless. --inspired by The Tao of Programming ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
On 10/29/05, Jiawei Ye [EMAIL PROTECTED] wrote: The problem is in sis.ko. Delete this file (disabling dri/drm only in xorg.conf is not useful), and Xorg will work again. I have raised this issue in the past, but no one responded. Did you submit a PR? Bryan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP! 6.0-RELEASE coming
I'm happy to hear that many bugs were fixed. :) But speedtouch usb modem still doesn't work with betas and last rc1. I submitted this some month ago: http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/83504 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
On 10/27/05, Scott Long [EMAIL PROTECTED] wrote: All, Wanted to let everyone know that the testing on RC1 has gone well enough that we've decided to skip RC2 and go straight to 6.0-RELEASE. Everyone that we have talked to has applauded the stability and functionality of the system, so we are really pleased and really eager to wrap it up and get it out to everyone. Over the next 24 hours we will be synchronizing the RELENG_6_0 tree to get in all of the appropriate bug fixes, then we will do some test builds as a final verification. Everyone is still welcome to update their sources on the RELENG_6_0 branch and provide feedback for the next 48 hours or so. The release will likely be announced by the end of the weekend or early next week, at the latest. I had a few issues with SiS 630 video driver, already related in thread http://docs.freebsd.org/cgi/getmsg.cgi?fetch=815881+0+/usr/local/www/db/text/2005/freebsd-current/20051016.freebsd-current Are those corrected already? I did compile the latest kernel (after a cvsup on src-sys*) and X.org still reboots my machine if I enable the SiS driver. -- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
Felipe openglx wrote: On 10/27/05, Scott Long [EMAIL PROTECTED] wrote: All, Wanted to let everyone know that the testing on RC1 has gone well enough that we've decided to skip RC2 and go straight to 6.0-RELEASE. Everyone that we have talked to has applauded the stability and functionality of the system, so we are really pleased and really eager to wrap it up and get it out to everyone. Over the next 24 hours we will be synchronizing the RELENG_6_0 tree to get in all of the appropriate bug fixes, then we will do some test builds as a final verification. Everyone is still welcome to update their sources on the RELENG_6_0 branch and provide feedback for the next 48 hours or so. The release will likely be announced by the end of the weekend or early next week, at the latest. I had a few issues with SiS 630 video driver, already related in thread http://docs.freebsd.org/cgi/getmsg.cgi?fetch=815881+0+/usr/local/www/db/text/2005/freebsd-current/20051016.freebsd-current Are those corrected already? I did compile the latest kernel (after a cvsup on src-sys*) and X.org still reboots my machine if I enable the SiS driver. -- [EMAIL PROTECTED] You'll need to work with the X11 developers. X is only something that FreeBSD includes as a 3rd party package, it's not something that we work on as part of the OS. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
On 10/28/05, Scott Long [EMAIL PROTECTED] wrote: You'll need to work with the X11 developers. X is only something that FreeBSD includes as a 3rd party package, it's not something that we work on as part of the OS. That's odd, because X11 always worked on that machine, on any linux distro and even on freebsd (4.x, 5.x, but NOT 6.x). Maybe some kernel driver changed and broke the compatibility between X11 and FreeBSD for that video card? -- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
Felipe openglx wrote: On 10/28/05, Scott Long [EMAIL PROTECTED] wrote: You'll need to work with the X11 developers. X is only something that FreeBSD includes as a 3rd party package, it's not something that we work on as part of the OS. That's odd, because X11 always worked on that machine, on any linux distro and even on freebsd (4.x, 5.x, but NOT 6.x). Maybe some kernel driver changed and broke the compatibility between X11 and FreeBSD for that video card? Was that working X11 X.Org or XFree86? Older releases contains XFree86 and 6.0 contains X.Org. You can find both as a FreeBSD port under x11-servers category. Give XFree86 a try, maybe it is better for You. Cheers, Gabor Kovesdan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
On Friday 28 October 2005 12:06 pm, Kövesdán Gábor wrote: Felipe openglx wrote: On 10/28/05, Scott Long [EMAIL PROTECTED] wrote: You'll need to work with the X11 developers. X is only something that FreeBSD includes as a 3rd party package, it's not something that we work on as part of the OS. That's odd, because X11 always worked on that machine, on any linux distro and even on freebsd (4.x, 5.x, but NOT 6.x). Maybe some kernel driver changed and broke the compatibility between X11 and FreeBSD for that video card? Was that working X11 X.Org or XFree86? Older releases contains XFree86 and 6.0 contains X.Org. You can find both as a FreeBSD port under x11-servers category. Give XFree86 a try, maybe it is better for You. Or xorg-server-snap, maybe... Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP! 6.0-RELEASE coming
All, Wanted to let everyone know that the testing on RC1 has gone well enough that we've decided to skip RC2 and go straight to 6.0-RELEASE. Everyone that we have talked to has applauded the stability and functionality of the system, so we are really pleased and really eager to wrap it up and get it out to everyone. Over the next 24 hours we will be synchronizing the RELENG_6_0 tree to get in all of the appropriate bug fixes, then we will do some test builds as a final verification. Everyone is still welcome to update their sources on the RELENG_6_0 branch and provide feedback for the next 48 hours or so. The release will likely be announced by the end of the weekend or early next week, at the latest. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
Wanted to let everyone know that the testing on RC1 has gone well enough that we've decided to skip RC2 and go straight to 6.0-RELEASE. Everyone that we have talked to has applauded the stability and functionality of the system, so we are really pleased and really eager to wrap it up and get it out to everyone. Indeed, I've been using 6.0 since BETA1 for a very long time and it seems stable like a rock. Congratulations! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
On Thu, 27 Oct 2005 20:09:36 +0200 Felipe Alfaro Solana [EMAIL PROTECTED] wrote: Wanted to let everyone know that the testing on RC1 has gone well enough that we've decided to skip RC2 and go straight to 6.0-RELEASE. Everyone that we have talked to has applauded the stability and functionality of the system, so we are really pleased and really eager to wrap it up and get it out to everyone. Indeed, I've been using 6.0 since BETA1 for a very long time and it seems stable like a rock. Congratulations! One thing I noticed with the ata code on 6.x. Put in a CF to your PCMCIA to CF adaptor and try to boot your laptop. The kernel will immidiately core dump. This never happened on 5.x. #uname -a FreeBSD lapdance.yazzy.net 6.0-RC1 FreeBSD 6.0-RC1 #12: Wed Oct 12 09:06:40 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LAPDANCE i386 Cheers, Marcin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
Marcin Jessa wrote: On Thu, 27 Oct 2005 20:09:36 +0200 Felipe Alfaro Solana [EMAIL PROTECTED] wrote: Wanted to let everyone know that the testing on RC1 has gone well enough that we've decided to skip RC2 and go straight to 6.0-RELEASE. Everyone that we have talked to has applauded the stability and functionality of the system, so we are really pleased and really eager to wrap it up and get it out to everyone. Indeed, I've been using 6.0 since BETA1 for a very long time and it seems stable like a rock. Congratulations! One thing I noticed with the ata code on 6.x. Put in a CF to your PCMCIA to CF adaptor and try to boot your laptop. The kernel will immidiately core dump. This never happened on 5.x. #uname -a FreeBSD lapdance.yazzy.net 6.0-RC1 FreeBSD 6.0-RC1 #12: Wed Oct 12 09:06:40 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LAPDANCE i386 Cheers, Marcin This was just fixed a couple of hours ago. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
On 27/10/2005, at 21:12, Marcin Jessa wrote: On Thu, 27 Oct 2005 20:09:36 +0200 Felipe Alfaro Solana [EMAIL PROTECTED] wrote: Wanted to let everyone know that the testing on RC1 has gone well enough that we've decided to skip RC2 and go straight to 6.0-RELEASE. Everyone that we have talked to has applauded the stability and functionality of the system, so we are really pleased and really eager to wrap it up and get it out to everyone. Indeed, I've been using 6.0 since BETA1 for a very long time and it seems stable like a rock. Congratulations! One thing I noticed with the ata code on 6.x. Put in a CF to your PCMCIA to CF adaptor and try to boot your laptop. The kernel will immidiately core dump. This never happened on 5.x. #uname -a FreeBSD lapdance.yazzy.net 6.0-RC1 FreeBSD 6.0-RC1 #12: Wed Oct 12 09:06:40 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LAPDANCE i386 I've just committed a fix for this a few hours ago.. Søren Schmidt [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
What about Gleb Smirnoff NFS locking leak patch ? I put it on production, everything works just fine. The question is: this patch will be merged to main source tree for 6.0-RELEASE ? Scott Long wrote: SL Wanted to let everyone know that the testing on RC1 has gone well enough SL that we've decided to skip RC2 and go straight to 6.0-RELEASE. Everyone SL that we have talked to has applauded the stability and functionality of SL the system, so we are really pleased and really eager to wrap it up and SL get it out to everyone. Over the next 24 hours we will be synchronizing SL the RELENG_6_0 tree to get in all of the appropriate bug fixes, then we SL will do some test builds as a final verification. Everyone is still SL welcome to update their sources on the RELENG_6_0 branch and provide SL feedback for the next 48 hours or so. The release will likely be SL announced by the end of the weekend or early next week, at the latest. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
Vladimir Sharun wrote: What about Gleb Smirnoff NFS locking leak patch ? I put it on production, everything works just fine. The question is: this patch will be merged to main source tree for 6.0-RELEASE ? Scott Long wrote: SL Wanted to let everyone know that the testing on RC1 has gone well enough SL that we've decided to skip RC2 and go straight to 6.0-RELEASE. Everyone SL that we have talked to has applauded the stability and functionality of SL the system, so we are really pleased and really eager to wrap it up and SL get it out to everyone. Over the next 24 hours we will be synchronizing SL the RELENG_6_0 tree to get in all of the appropriate bug fixes, then we SL will do some test builds as a final verification. Everyone is still SL welcome to update their sources on the RELENG_6_0 branch and provide SL feedback for the next 48 hours or so. The release will likely be SL announced by the end of the weekend or early next week, at the latest. I beleive that this was committed a few hours ago. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
On Thu, Oct 27, 2005 at 10:43:35PM +0300, Vladimir Sharun wrote: What about Gleb Smirnoff NFS locking leak patch ? I put it on production, everything works just fine. The question is: this patch will be merged to main source tree for 6.0-RELEASE ? It already was. Kris pgpDf8ksiSV4z.pgp Description: PGP signature
Re: HEADS UP! 6.0-RELEASE coming
On Thu, 27 Oct 2005 21:21:51 +0200 Søren Schmidt [EMAIL PROTECTED] wrote: On 27/10/2005, at 21:12, Marcin Jessa wrote: On Thu, 27 Oct 2005 20:09:36 +0200 Felipe Alfaro Solana [EMAIL PROTECTED] wrote: Wanted to let everyone know that the testing on RC1 has gone well enough that we've decided to skip RC2 and go straight to 6.0-RELEASE. Everyone that we have talked to has applauded the stability and functionality of the system, so we are really pleased and really eager to wrap it up and get it out to everyone. Indeed, I've been using 6.0 since BETA1 for a very long time and it seems stable like a rock. Congratulations! One thing I noticed with the ata code on 6.x. Put in a CF to your PCMCIA to CF adaptor and try to boot your laptop. The kernel will immidiately core dump. This never happened on 5.x. #uname -a FreeBSD lapdance.yazzy.net 6.0-RC1 FreeBSD 6.0-RC1 #12: Wed Oct 12 09:06:40 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LAPDANCE i386 I've just committed a fix for this a few hours ago.. I just rebuilt my kernel and the issue is indeed gone. Great work as usual. Thanks Søren! Marcin. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
