Deprecating ps(1)s -w switch
I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. -- Brian Somers br...@awfulhak.org Don't _EVER_ lose your sense of humour ! br...@freebsd.org signature.asc Description: PGP signature
tree doesnt compile
/usr/src/sys/modules/vesa/../../i386/isa/vesa.c: In function 'vesa_set_mode': /usr/src/sys/modules/vesa/../../i386/isa/vesa.c:1117: error: duplicate case value anyone seeing this as well or is this a local f***up ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: tree doesnt compile
Am 25.08.2009 um 13:23 schrieb Marc Balmer: /usr/src/sys/modules/vesa/../../i386/isa/vesa.c: In function 'vesa_set_mode': /usr/src/sys/modules/vesa/../../i386/isa/vesa.c:1117: error: duplicate case value anyone seeing this as well or is this a local f***up ? fwiw, problem is still there after 'make clean make kernel' ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
On Tue, Aug 25, 2009 at 03:40:54AM -0700, Brian Somers wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Do you want to remove '-w' switch preserving '-ww' one? IMO this seems awkward. Also, by ignoring it for now do you mean that behavior of ps with '-w' switch would be the same as without it? I would prefer that '-w' == '-ww'. One can remove all references to multiple 'w' switches from the man page but leave ps itself insensitive to any number of 'w' switches (so '-w' == '-ww' == '-www' == ...). This also would be consistent with (for example) http://www.freebsd.org/cgi/man.cgi?query=psapropos=0sektion=0manpath=Red+Hat+Linux%2Fi386+9format=html Does anyone have any objections to doing this? I don't propose merging this back into stable/8. 0.02$, Alexey. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
* Brian Somers br...@freebsd.org wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. So ps(1) output can never be limited to the screen width? -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgp2fY6nDMwf4.pgp Description: PGP signature
Re: Deprecating ps(1)s -w switch
On Tuesday 25 August 2009 15:44:47 Ed Schouten wrote: * Brian Somers br...@freebsd.org wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. So ps(1) output can never be limited to the screen width? I usually want to see ps(1) output in easily-read columns. Without width limits, this can't be guaranteed. I would strongly object to the complete removal of any option to limit the output width of ps(1) and make it easily human-readable. I'm also astonished at the suggestion that not using -ww is ``a mistake''. I very seldom need to see the whole commandline for every process. Jonathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: tree doesnt compile
* Marc Balmer m...@msys.ch wrote: Am 25.08.2009 um 13:23 schrieb Marc Balmer: /usr/src/sys/modules/vesa/../../i386/isa/vesa.c: In function 'vesa_set_mode': /usr/src/sys/modules/vesa/../../i386/isa/vesa.c:1117: error: duplicate case value anyone seeing this as well or is this a local f***up ? fwiw, problem is still there after 'make clean make kernel' svn up ;-) -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpj3vfbw7jBz.pgp Description: PGP signature
Re: Deprecating ps(1)s -w switch
Ed Schouten napisa: * Brian Somers br...@freebsd.org wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. So ps(1) output can never be limited to the screen width? I think it would be smart not to limit width by default (ie default behavior to be like with -ww), but to have some switch (like -w) to limit width if someone really needs to do that, although with cut -c 1-80 could be achieved limiting... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
* Adrian Penisoara a...@freebsd.ady.ro wrote: Maybe we should also think about compatibility with System V Unix / Linux -- I have encountered quite a lot of scripts expecting ps -ef to give an all processes output. It would not hurt to review what the Linux folks did with their ps(1) -- it supports 3 kinds of options for UNIX/BSD/GNU flavors. In my opinion we should just implement ps(1) as documented in the POSIX Onlinepubs. If it turns out it lacks certain features we want, we could consider adding this to procstat(1) instead. I am of course too lazy to work on this. ;-) -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpcZxeT4pqza.pgp Description: PGP signature
Re: Deprecating ps(1)s -w switch
Hi, On Tue, Aug 25, 2009 at 3:59 PM, Ivan Radovanovic riv...@gmail.com wrote: Ed Schouten napisa: * Brian Somers br...@freebsd.org wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. So ps(1) output can never be limited to the screen width? I think it would be smart not to limit width by default (ie default behavior to be like with -ww), but to have some switch (like -w) to limit width if someone really needs to do that, although with cut -c 1-80 could be achieved limiting... Let's not reverse the meaning of switches, for the sake of compatibility with (older) existent scripts... Maybe we should also think about compatibility with System V Unix / Linux -- I have encountered quite a lot of scripts expecting ps -ef to give an all processes output. It would not hurt to review what the Linux folks did with their ps(1) -- it supports 3 kinds of options for UNIX/BSD/GNU flavors. Regards, Adrian Penisoara EnterpriseBSD ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Jonathan McKeown wrote: On Tuesday 25 August 2009 15:44:47 Ed Schouten wrote: * Brian Somers br...@freebsd.org wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. The difference between ps, ps -w, and ps -ww is pretty significant for Java, in particular. Java command lines are typically enormous (thank you, CLASSPATH) which makes ps -ww often more annoying than it's worth. I concur with another poster that the GNU ps approach for supporting multiple argument styles deserves consideration. Tim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
On Tue, 2009-08-25 at 08:48 -0700, Tim Kientzle wrote: Jonathan McKeown wrote: On Tuesday 25 August 2009 15:44:47 Ed Schouten wrote: * Brian Somers br...@freebsd.org wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. The difference between ps, ps -w, and ps -ww is pretty significant for Java, in particular. Java command lines are typically enormous (thank you, CLASSPATH) which makes ps -ww often more annoying than it's worth. I concur with another poster that the GNU ps approach for supporting multiple argument styles deserves consideration. I realized that nobody asked me, but IMHO it ain't broke so don't fix it. I use -w and -ww a lot, and yes, I do distinguish them. Sometimes -w is enough; if it isn't, then I'll use -ww but otherwise I avoid it because it gives just too much output in many cases. -- Frank Mayhar fr...@exit.com http://www.exit.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
GA-MA780G-UD3H motherboard
I have become to own Gigabyte GA-MA780G-UD3H motherboard: http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ClassValue=MotherboardProductID=3004ProductName=GA-MA780G-UD3H It is based on AMD 780G + SB700. BTW, CPU I am using is Athlon II X2 250. Sorry for the broadcast announcement, but this is my first AMD-based system in many years, so I eagerly started exploring it and hacking for it. For this reason please expect a number of questions from me as well as some reports and hopefully code related to this motherboard. I am going to post them as follow-ups to this email. Meanwhile, if you interested in any information about this motherboard - data dumps, outputs from tools, etc - please let me know, I will try my best to provide that. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
AMD SB700 watchdog driver?
Anybody has any code for AMD SB700 watchdog driver? I see that there is none in FreeBSD and I'd like to write one. So I could re-use anything that you have for a faster start. In any case, I expect the driver to be rather simple. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
AMD SB700 SMBus controller driver
According to SB700 specifications its SMBus controller is very similar to one in PIIX4. The differences that I see so far: 1. Interrupt Line/Interrupt Pin PCI configuration registers (0x3c, 0x3d) do not specify interrupt number that the controller could use: This register specifies which interrupt pin the device issue This module does not generate interrupt but contains the actual interrupt controller. This register is hardcoded to 0. 2. I2CbusConfig register (0xd2) uses bit #1 to indicate whether SMI or regular interrupt is used in interrupt mode; PIIX4 uses bit 3. I couldn't get our intpm driver to work with this hardware by simply adding PCI id and tweaking 0xd2 bits meaning. I could get it to work by forcing polling mode. It appears that Linux driver for this HW always uses polling mode, and OpenBSD and NetBSD drivers would use it with this HW too. I am still trying to get interrupt mode to work. I set 0xd2 to enable regular interrupt generation (it is set to SMI after boot). SB700 specifications say at one place that SMB interrupt is connected to INTIN20 pin of IO-APIC in APIC mode. I tried setting up IRQ20 in the driver but no interrupts are generated. And there are no stray interrupts either. So I am not sure - either this HW doesn't generate normal interrupts at all, or they to a different pin, or additional setup is required, or I am doing something wrong. Anyway, I plan to produce an updated version of intpm driver with possibility of forced or auto-detected polling mode and support for PCI id of SB700 SMBus controller and its peculiarities. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
GA-MA780G-UD3H hardware monitoring
Does anybody know if Gigabyte provides special ACPI interfaces for HWM on their motherboards? Maybe something like ASUS does (acpi_aiboost)? Or do they access HWM chip directly? They have this EasyTune software, so they must be doing something. DSDT of GA-MA780G-UD3H doesn't even provide TZ. This motherboard has iTE IT8718 Super I/O + HWM chip. Thanks to superiotool from coreboot project I determined that base address (port actually) for HWM logical device is at 0x228 (as opposed to more typical 0x290). Slightly modified version of mbmon is even able to recognize the chip and get some data. I am not sure if the data is entirely correct, but it looks sane/reasonable. Still I would like to not only monitor temperatures, voltages and fan speeds, but even to be able to control fan speed. Any links, pointers, ideas, code would be very appreciated! -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Brian Somers wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. my fingers would object as ps auxw is my standard command. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Brian Somers wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. Short version, yes, I object to changing the defaults. Longer version, I don't see anything wrong with the defaults the way that they are, and the fact that there is a teeny-tiny learning curve for people who need to see the full output isn't really an issue that deserves the time already spent on it. Bruce pointed out in the PR that most users would be surprised if 'ps -ax | grep foo' suddenly sprouted a lot more stuff that 'ps -ax' didn't have, and I agree. As a matter of personal preference I find the current defaults to be just lovely, and occasionally use -w or -ww if I need to see more. If you want the default to be something different, that's what aliases are for. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Doug Barton napisa: Brian Somers wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. Short version, yes, I object to changing the defaults. Longer version, I don't see anything wrong with the defaults the way that they are, and the fact that there is a teeny-tiny learning curve for people who need to see the full output isn't really an issue that deserves the time already spent on it. Bruce pointed out in the PR that most users would be surprised if 'ps -ax | grep foo' suddenly sprouted a lot more stuff that 'ps -ax' didn't have, and I agree. As a matter of personal preference I find the current defaults to be just lovely, and occasionally use -w or -ww if I need to see more. If you want the default to be something different, that's what aliases are for. Doug So, if the developer is presented with a task of developing utility to list running processes on the machine the right way to solve this problem is to implement it exactly the way the ps is implemented (ie, to please some aesthetic criteria (ie to format output to some width) rather than to focus on functionality)? I think software should evolve to be better rather then to stick with something done the wrong way, even that has been done maybe 30 years ago - that is why behavior should be changed. It is never too late to do the right thing ;-) Best regards, Ivan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Ivan Radovanovic wrote: So, if the developer is presented with a task of developing utility to list running processes on the machine the right way to solve this problem is to implement it exactly the way the ps is implemented (ie, to please some aesthetic criteria (ie to format output to some width) rather than to focus on functionality)? If you're developing your own app to display running processes implement it any way you wish. That's totally unrelated to the question at hand. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Doug Barton napisa: If you're developing your own app to display running processes implement it any way you wish. That's totally unrelated to the question at hand. Doug I totally disagree with you - being against change means that you believe it is done the best way it could be done. Although there is another way to solve this problem - manual can be changed to state in the first row process status formated for terminal output instead of process status which is now title for ps. That way it would be obvious at the first look that ps is tightly coupled with terminal it is running on and nobody would need to learn this harder way. Regards, Ivan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Ivan Radovanovic wrote: Doug Barton napisa: If you're developing your own app to display running processes implement it any way you wish. That's totally unrelated to the question at hand. Doug I totally disagree with you - being against change means that you believe it is done the best way it could be done. This argument is so non-sequitur that I'm tempted not to respond, but no, that's not what I'm saying at all. What I'm saying is that there are valid reasons to leave the defaults as they are, AND if you don't like the defaults there are easy ways to manipulate that in your own environment. Although there is another way to solve this problem - manual can be changed to state in the first row process status formated for terminal output instead of process status which is now title for ps. That way it would be obvious at the first look that ps is tightly coupled with terminal it is running on and nobody would need to learn this harder way. Feel free to take a crack at this and send the results to the list for review. Improving the documentation is always a worthy goal. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GA-MA780G-UD3H motherboard
Meanwhile, if you interested in any information about this motherboard - data dumps, outputs from tools, etc - please let me know, I will try my best to provide that. it would be interesting to see a dmesg as a starting point. Sam Fourman Jr. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Doug Barton napisa: Ivan Radovanovic wrote: I totally disagree with you - being against change means that you believe it is done the best way it could be done. This argument is so non-sequitur that I'm tempted not to respond, but no, that's not what I'm saying at all. What I'm saying is that there are valid reasons to leave the defaults as they are, AND if you don't like the defaults there are easy ways to manipulate that in your own environment. You wrote : Longer version, I don't see anything wrong with the defaults the way that they are, and the fact that there is a teeny-tiny learning curve for people who need to see the full output isn't really an issue that deserves the time already spent on it. Bruce pointed out in the PR that most users would be surprised if 'ps -ax | grep foo' suddenly sprouted a lot more stuff that 'ps -ax' didn't have, and I agree. As a matter of personal preference I find the current defaults to be just lovely, and occasionally use -w or -ww if I need to see more. If you want the default to be something different, that's what aliases are for. So, valid arguments against change should be: 1. users will be surprised if ps starts displaying more stuff no matter if that stuff is correct and less stuff (current state) is incorrect 2. your personal preference is that current defaults are lovely Sorry, I don't find these arguments valid Although there is another way to solve this problem - manual can be changed to state in the first row process status formated for terminal output instead of process status which is now title for ps. That way it would be obvious at the first look that ps is tightly coupled with terminal it is running on and nobody would need to learn this harder way. Feel free to take a crack at this and send the results to the list for review. Improving the documentation is always a worthy goal. I would do that for sure if everyone thinks this ps behavior is something that should be kept at current state even if it could be made better Ivan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GA-MA780G-UD3H motherboard
On Tue, 2009-08-25 at 21:27 +0200, Thierry Herbelot wrote: Le Tuesday 25 August 2009, Sam Fourman Jr. a écrit : Meanwhile, if you interested in any information about this motherboard - data dumps, outputs from tools, etc - please let me know, I will try my best to provide that. it would be interesting to see a dmesg as a starting point. here you are ;-) I have plugged a PCI sound board in the machine, but it does seem to be detected (there could be some issue with PCI bus enumeration : I also include a pciconf log) I'm curious why you would plug in a pci sound card? You already have both a standard hda codec as well as the hda codec for the hdmi port of the video. If you are discovering that it isn't working... set hw.snd.default_unit=1 which is typcially your normal analog audio port. The hdmi port on radeon chips tends to be enumerated before the normal system codecs, so people tend to think that sound isn't working. robert. TfH Sam Fourman Jr. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-STABLE #12: Mon Jul 6 09:37:34 CEST 2009 x...@yyy:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ (3106.64-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x60fb2 Stepping = 2 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x2001SSE3,CX16 AMD Features=0xea500800SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x11fLAHF,CMP,SVM,ExtAPIC,CR8,Prefetch TSC: P-state invariant Cores per package: 2 usable memory = 4008947712 (3823 MB) avail memory = 3836862464 (3659 MB) ACPI APIC Table: GBTGBTUACPI FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ ioapic0: Changing APIC ID to 2 ioapic0 Version 2.1 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: GBT GBTUACPI on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, bfce (3) failed Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 32-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0xee00-0xeeff mem 0xd000-0xdfff,0xfdfe-0xfdfe,0xfde0-0xfdef irq 18 at device 5.0 on pci1 hdac0: ATI RS780 High Definition Audio Controller mem 0xfdffc000-0xfdff irq 19 at device 5.1 on pci1 hdac0: HDA Driver Revision: 20090329_0131 hdac0: [ITHREAD] pcib2: ACPI PCI-PCI bridge irq 18 at device 10.0 on pci0 pci2: ACPI PCI bus on pcib2 re0: RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe Gigabit Ethernet port 0xde00-0xdeff mem 0xfdaff000-0xfdaf,0xfdae-0xfdae irq 18 at device 0.0 on pci2 re0: Using 1 MSI messages re0: Chip rev. 0x3c00 re0: MAC rev. 0x0040 miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211B media interface PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1f:d0:56:75:23 re0: [FILTER] atapci0: ATI AHCI controller port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 17.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 6 ports detected ata2: ATA channel 0 on atapci0 ata2: [ITHREAD] ata3: ATA channel 1 on atapci0 ata3: [ITHREAD] ata4: ATA channel 2 on atapci0 ata4: [ITHREAD] ata5: ATA channel 3 on atapci0 ata5: [ITHREAD] ata6: ATA channel 4 on atapci0 ata6: [ITHREAD] ata7: ATA channel 5 on atapci0 ata7: [ITHREAD] ohci0: OHCI (generic) USB controller mem 0xfe02e000-0xfe02efff irq 16 at device 18.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: ATI OHCI root hub, class 9/0, rev
Re: Deprecating ps(1)s -w switch
,--- You/Ivan (Tue, 25 Aug 2009 22:02:56 +0200) * | Feel free to take a crack at this and send the results to the list for | review. Improving the documentation is always a worthy goal. | | I would do that for sure if everyone thinks this ps behavior is | something that should be kept at current state even if it could be made | better `---* Don't know how you are going to find about everyone, but I, for one, think that modifying the established tool's behavior in the proposed manner is an utterly bad idea. Use shell aliases, functions and scripts wrapped around the primary tool to get the behavior you like -- let others stick with their established habits and wrappers. Improving the documentation would be good, OTOH. Thanks, -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
On Tuesday 25 August 2009 4:02:56 pm Ivan Radovanovic wrote: Doug Barton napisa: Ivan Radovanovic wrote: I totally disagree with you - being against change means that you believe it is done the best way it could be done. This argument is so non-sequitur that I'm tempted not to respond, but no, that's not what I'm saying at all. What I'm saying is that there are valid reasons to leave the defaults as they are, AND if you don't like the defaults there are easy ways to manipulate that in your own environment. You wrote : Longer version, I don't see anything wrong with the defaults the way that they are, and the fact that there is a teeny-tiny learning curve for people who need to see the full output isn't really an issue that deserves the time already spent on it. Bruce pointed out in the PR that most users would be surprised if 'ps -ax | grep foo' suddenly sprouted a lot more stuff that 'ps -ax' didn't have, and I agree. As a matter of personal preference I find the current defaults to be just lovely, and occasionally use -w or -ww if I need to see more. If you want the default to be something different, that's what aliases are for. So, valid arguments against change should be: 1. users will be surprised if ps starts displaying more stuff no matter if that stuff is correct and less stuff (current state) is incorrect 2. your personal preference is that current defaults are lovely POLA -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
On Tue, Aug 25, 2009 at 04:09:09PM +0200, Jonathan McKeown wrote: I usually want to see ps(1) output in easily-read columns. Without width limits, this can't be guaranteed. I would strongly object to the complete removal of any option to limit the output width of ps(1) and make it easily human-readable. I'm also astonished at the suggestion that not using -ww is ``a mistake''. I very seldom need to see the whole commandline for every process. Then you must not use Java much. I almost always need the -ww option. I'm fine with the default being fit into my terminal width, but I'd be for one option to specify limited width and another option (-w) to specify as wide as possible. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GA-MA780G-UD3H motherboard
Le Tuesday 25 August 2009, Sam Fourman Jr. a écrit : Meanwhile, if you interested in any information about this motherboard - data dumps, outputs from tools, etc - please let me know, I will try my best to provide that. it would be interesting to see a dmesg as a starting point. here you are ;-) I have plugged a PCI sound board in the machine, but it does seem to be detected (there could be some issue with PCI bus enumeration : I also include a pciconf log) TfH Sam Fourman Jr. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-STABLE #12: Mon Jul 6 09:37:34 CEST 2009 x...@yyy:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ (3106.64-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x60fb2 Stepping = 2 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x2001SSE3,CX16 AMD Features=0xea500800SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x11fLAHF,CMP,SVM,ExtAPIC,CR8,Prefetch TSC: P-state invariant Cores per package: 2 usable memory = 4008947712 (3823 MB) avail memory = 3836862464 (3659 MB) ACPI APIC Table: GBTGBTUACPI FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ ioapic0: Changing APIC ID to 2 ioapic0 Version 2.1 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: GBT GBTUACPI on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, bfce (3) failed Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 32-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0xee00-0xeeff mem 0xd000-0xdfff,0xfdfe-0xfdfe,0xfde0-0xfdef irq 18 at device 5.0 on pci1 hdac0: ATI RS780 High Definition Audio Controller mem 0xfdffc000-0xfdff irq 19 at device 5.1 on pci1 hdac0: HDA Driver Revision: 20090329_0131 hdac0: [ITHREAD] pcib2: ACPI PCI-PCI bridge irq 18 at device 10.0 on pci0 pci2: ACPI PCI bus on pcib2 re0: RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe Gigabit Ethernet port 0xde00-0xdeff mem 0xfdaff000-0xfdaf,0xfdae-0xfdae irq 18 at device 0.0 on pci2 re0: Using 1 MSI messages re0: Chip rev. 0x3c00 re0: MAC rev. 0x0040 miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211B media interface PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1f:d0:56:75:23 re0: [FILTER] atapci0: ATI AHCI controller port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 17.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 6 ports detected ata2: ATA channel 0 on atapci0 ata2: [ITHREAD] ata3: ATA channel 1 on atapci0 ata3: [ITHREAD] ata4: ATA channel 2 on atapci0 ata4: [ITHREAD] ata5: ATA channel 3 on atapci0 ata5: [ITHREAD] ata6: ATA channel 4 on atapci0 ata6: [ITHREAD] ata7: ATA channel 5 on atapci0 ata7: [ITHREAD] ohci0: OHCI (generic) USB controller mem 0xfe02e000-0xfe02efff irq 16 at device 18.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 uhub0: 3 ports with 3 removable, self powered ohci1: OHCI (generic) USB controller mem 0xfe02d000-0xfe02dfff irq 16 at device 18.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: OHCI (generic) USB controller on ohci1 usb1: USB revision 1.0 uhub1: ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb1 uhub1: 3 ports with 3 removable, self powered ehci0: EHCI (generic) USB 2.0 controller mem 0xfe02c000-0xfe02c0ff irq 17 at device 18.2 on pci0 ehci0: [GIANT-LOCKED] ehci0:
Re: GA-MA780G-UD3H motherboard
Le Tuesday 25 August 2009, Robert Noland a écrit : On Tue, 2009-08-25 at 21:27 +0200, Thierry Herbelot wrote: Le Tuesday 25 August 2009, Sam Fourman Jr. a écrit : Meanwhile, if you interested in any information about this motherboard - data dumps, outputs from tools, etc - please let me know, I will try my best to provide that. it would be interesting to see a dmesg as a starting point. here you are ;-) I have plugged a PCI sound board in the machine, but it does seem to be detected (there could be some issue with PCI bus enumeration : I also include a pciconf log) I'm curious why you would plug in a pci sound card? You already have both a standard hda codec as well as the hda codec for the hdmi port of the video. If you are discovering that it isn't working... set Initially, this was the issue, before other people sent various howtos around the probe of the hdmi hda port (which by the way sounds *much* better than my previous cmi board). Afterwards, the PCI board remained in the machine (leftover from a previous box), but it is still *not* seen by the PCI enumeration (I'm a bit too lazy to find another spare PCI board and plug it in see what happens : is it also ignored by the BIOS/ACPI/whatever and/or the kernel ?). It seems that it is not either detected by a Linux kernel. TfH hw.snd.default_unit=1 which is typcially your normal analog audio port. The hdmi port on radeon chips tends to be enumerated before the normal system codecs, so people tend to think that sound isn't working. robert. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GA-MA780G-UD3H motherboard
On Tue, 2009-08-25 at 22:14 +0200, Thierry Herbelot wrote: Le Tuesday 25 August 2009, Robert Noland a écrit : On Tue, 2009-08-25 at 21:27 +0200, Thierry Herbelot wrote: Le Tuesday 25 August 2009, Sam Fourman Jr. a écrit : Meanwhile, if you interested in any information about this motherboard - data dumps, outputs from tools, etc - please let me know, I will try my best to provide that. it would be interesting to see a dmesg as a starting point. here you are ;-) I have plugged a PCI sound board in the machine, but it does seem to be detected (there could be some issue with PCI bus enumeration : I also include a pciconf log) I'm curious why you would plug in a pci sound card? You already have both a standard hda codec as well as the hda codec for the hdmi port of the video. If you are discovering that it isn't working... set Initially, this was the issue, before other people sent various howtos around the probe of the hdmi hda port (which by the way sounds *much* better than my previous cmi board). Afterwards, the PCI board remained in the machine (leftover from a previous box), but it is still *not* seen by the PCI enumeration (I'm a bit too lazy to find another spare PCI board and plug it in see what happens : is it also ignored by the BIOS/ACPI/whatever and/or the kernel ?). It seems that it is not either detected by a Linux kernel. Perhaps it isn't seated properly? Or possibly a different slot might help. robert. TfH hw.snd.default_unit=1 which is typcially your normal analog audio port. The hdmi port on radeon chips tends to be enumerated before the normal system codecs, so people tend to think that sound isn't working. robert. -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Alex Goncharov napisa: ,--- You/Ivan (Tue, 25 Aug 2009 22:02:56 +0200) * | Feel free to take a crack at this and send the results to the list for | review. Improving the documentation is always a worthy goal. | | I would do that for sure if everyone thinks this ps behavior is | something that should be kept at current state even if it could be made | better `---* Don't know how you are going to find about everyone, but I, for one, think that modifying the established tool's behavior in the proposed manner is an utterly bad idea. Use shell aliases, functions and scripts wrapped around the primary tool to get the behavior you like -- let others stick with their established habits and wrappers. Improving the documentation would be good, OTOH. Thanks, -- Alex -- alex-goncha...@comcast.net -- I guess voting is going against me, so I would probably need to update that documentation :-) Please understand that my idea is to make tool behave as expected from its description - for example ls also formats its output according to terminal, but when you redirect it then it doesn't care about terminal (try ls and ls | less), that is what in the first place made me think that ps would behave in the same way (and btw, I still think that all non-interactive tools behave that way). And I also think that if we can make learning FreeBSD even little less difficult then we should do that. My point is if you are making tool for listing processes what you want is to LIST process (first, and most important), and later (if at all) to make that pretty formatted, after all it is unix philosophy to have small programs that do exactly one thing and that do it right - I think that philosophy is broken (because of historical reasons) with current implementation of ps On the other hand fixing ps's behavior in the proposed manner will for sure brake some scripts that depend on it, but if scripts depend on formatting behavior then those scripts are used only to display some information on the terminal and they would be easily spotted and corrected (are there scripts like that in the system - can someone point out and say Hey XXX will be broken, and that will further brake YYY and so on? Because I am beginning to think that maybe there is far less things depending on this behavior than expected... ) Ivan P.S. I am giving up of trying to explain my reasoning any more, I think I gave enough reasons for everyone to understand my motivation (although of course everyone has the right not to agree with me). I didn't want to offend anyone in this short discussion and if someone feels that way then I am truly sorry. Any pointers on how to update manual page for ps would be greatly appreciated, as well as some mail agreeing with my standpoint :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GA-MA780G-UD3H motherboard
On Tue, Aug 25, 2009 at 11:35 AM, Andriy Gapona...@freebsd.org wrote: I have become to own Gigabyte GA-MA780G-UD3H motherboard: http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ClassValue=MotherboardProductID=3004ProductName=GA-MA780G-UD3H It is based on AMD 780G + SB700. BTW, CPU I am using is Athlon II X2 250. are you using a i386 or AMD64 kernel? maybe I am blind but I didnt see it in your dmesg Sam Fourman Jr. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GA-MA780G-UD3H motherboard
Andriy Gapon said the following on 2009-08-25 18:35: I have become to own Gigabyte GA-MA780G-UD3H motherboard: http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ClassValue=MotherboardProductID=3004ProductName=GA-MA780G-UD3H It is based on AMD 780G + SB700. BTW, CPU I am using is Athlon II X2 250. Sorry for the broadcast announcement, but this is my first AMD-based system in many years, so I eagerly started exploring it and hacking for it. For this reason please expect a number of questions from me as well as some reports and hopefully code related to this motherboard. I am going to post them as follow-ups to this email. Meanwhile, if you interested in any information about this motherboard - data dumps, outputs from tools, etc - please let me know, I will try my best to provide that. It would be interesting to know if you can have usb devices connected and detected during boot. With SB600 you can not. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: AMD SB700 SMBus controller driver
Could you please forward me the patch to make it work in polling mode ? I'd like to test it as I've been trying to make intpm work with a SB400 (which should be quite the same as yours) but system hangs when I try to force polling mode (didn't have the specs nor all the differences you just presented). And btw, I didn't find any implementation using interrupt neither but I'm ready to test your updated version. Thanks, Aurélien - Original Message - From: Andriy Gapon a...@freebsd.org To: freebsd-a...@freebsd.org; freebsd-hackers@freebsd.org Sent: Tuesday, August 25, 2009 7:49 PM Subject: AMD SB700 SMBus controller driver According to SB700 specifications its SMBus controller is very similar to one in PIIX4. The differences that I see so far: 1. Interrupt Line/Interrupt Pin PCI configuration registers (0x3c, 0x3d) do not specify interrupt number that the controller could use: This register specifies which interrupt pin the device issue This module does not generate interrupt but contains the actual interrupt controller. This register is hardcoded to 0. 2. I2CbusConfig register (0xd2) uses bit #1 to indicate whether SMI or regular interrupt is used in interrupt mode; PIIX4 uses bit 3. I couldn't get our intpm driver to work with this hardware by simply adding PCI id and tweaking 0xd2 bits meaning. I could get it to work by forcing polling mode. It appears that Linux driver for this HW always uses polling mode, and OpenBSD and NetBSD drivers would use it with this HW too. I am still trying to get interrupt mode to work. I set 0xd2 to enable regular interrupt generation (it is set to SMI after boot). SB700 specifications say at one place that SMB interrupt is connected to INTIN20 pin of IO-APIC in APIC mode. I tried setting up IRQ20 in the driver but no interrupts are generated. And there are no stray interrupts either. So I am not sure - either this HW doesn't generate normal interrupts at all, or they to a different pin, or additional setup is required, or I am doing something wrong. Anyway, I plan to produce an updated version of intpm driver with possibility of forced or auto-detected polling mode and support for PCI id of SB700 SMBus controller and its peculiarities. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Ivan Radovanovic wrote: Doug Barton napisa: Ivan Radovanovic wrote: I totally disagree with you - being against change means that you believe it is done the best way it could be done. This argument is so non-sequitur that I'm tempted not to respond, but no, that's not what I'm saying at all. What I'm saying is that there are valid reasons to leave the defaults as they are, AND if you don't like the defaults there are easy ways to manipulate that in your own environment. I would do that for sure if everyone thinks this ps behavior is something that should be kept at current state even if it could be made better -w was added to show more information, and -ww for all information. I find no problem understanding this and see no reason to change it. blue please p.s. -ww can get big Ivan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GA-MA780G-UD3H motherboard
Le Tuesday 25 August 2009, Bernt Hansson a écrit : Andriy Gapon said the following on 2009-08-25 18:35: I have become to own Gigabyte GA-MA780G-UD3H motherboard: http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ClassV alue=MotherboardProductID=3004ProductName=GA-MA780G-UD3H It is based on AMD 780G + SB700. BTW, CPU I am using is Athlon II X2 250. Sorry for the broadcast announcement, but this is my first AMD-based system in many years, so I eagerly started exploring it and hacking for it. For this reason please expect a number of questions from me as well as some reports and hopefully code related to this motherboard. I am going to post them as follow-ups to this email. Meanwhile, if you interested in any information about this motherboard - data dumps, outputs from tools, etc - please let me know, I will try my best to provide that. It would be interesting to know if you can have usb devices connected and detected during boot. With SB600 you can not. This maybe the explanation why I have to re-plug the USB mouse each time the machine is restarted ;-) (with an SB700) TfH ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
At 11:50 AM -0700 8/25/09, Doug Barton wrote: Brian Somers wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. Short version, yes, I object to changing the defaults. Speaking as someone who has worked on 'ps' in the past, I recommend that you go slow in making arbitrary changes. 'ps' is already a minefield of craziness between various versions of unix, and adding this new variant will just make matters worse. You certainly can not go back to older releases and change the formatting there, so all programmers who write for a variety of machines/platforms will just end up with one extra way for things to break. -- Garance Alistair Drosehn = dros...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
