Re: eeePC 900 turning off wireless (ath0)
El día Friday, July 04, 2008 a las 04:40:02PM +0200, Matthias Apitz escribió: Hello Rui, With your changes of acpi_asus.c in RELENG_7 the devd(8) and my hook-script in /usr/local/etc/devd/ath.conf sees the Fn+F2 now as the event ACPI ASUS-Eee _SB_.ATKD, but it is anyway if Fn+F2 switches off or on the wireless NIC, the event for devd(8) is always the same; from the above event it is clear where the strings for system ACPI and subsystem ASUS-Eee come from, but I don't see where the string _SB_.ATKD is made; it must be derived from the 'notify' argument of the call /* Notify devd(8) */ acpi_UserNotify(ASUS-Eee, h, notify); and I was hoping to distinguish it into two different events, one when Fn+F2 is switching off the NIC, and one of the case of switch on; any idea? thx I have modified /usr/src/sys/dev/acpi_support/acpi_asus.c to see what 'notify' is send upstream to devd(8): /* Notify devd(8) */ device_printf(sc-dev, Fn+F2 pressed, notify to devd(8) is %08x\n, notify); acpi_UserNotify(ASUS-Eee, h, notify); and it turns out that in case of switching wireless of it is 0x0011, while on switch-on it is 0x0010; but the devd(8) only sees both events as '_SB_.ATKD'; I've grep'ed a lot around but can't see the place where the hex events of acpi_UserNotify() are converted into the string '_SB_.ATKD', any idea where to look; for the devd(8) hook it would be essential to know if the wireless was turned on of off, to load or unload the driver module if_ath.ko in that case and bring the interface up again (which works fine if I do it by hand); matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e [EMAIL PROTECTED] - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ «...una sola vez, que es cuanto basta si se trata de verdades definitivas.» «...only once, which is enough if it has todo with definite truth.» José Saramago, Historia del Cerca de Lisboa ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kgdb error: Ignoring packet error, continuing....
On Thu, Jul 3, 2008 at 1:47 PM, karim sk [EMAIL PROTECTED] wrote: Hi, I am trying to setup kgdb on serial console in freebsd. I have done the following steps. 1. Compile the kernel with the following options options DDB options KDB makeoptions DEBUG-g 2.Installed the kernel on the target machine. 3. Transferred the kernel.debug to host machine. 4. Modified the file /boot/device.hints in the target machine to have sio flags as hint.sio.0.at=isa hint.sio.0.port=0X3F8 hint.sio.0.flags=0x80 hint.sio.0.irq=4 5. Reboot the target machine. At the loader prompt type the following set comconsole_speed=9600 boot -d Then the target machine stops at ddb prompt. 6.In the host machine type the following at kgdb prompt kgdb set remotebaud 9600 kgdb file kernel.debug kgdb target remote /dev/cuad0 This is not able to establish the connection. It is giving following errors. Ignoring packet error, continuing... Ignoring packet error, continuing... Couldn't establish connection to remote target. Malformed response to offset query, timeout. Can any body tell why packet error is coming when kgdb is trying to establish the connection. Thanks in advance. Karim I am not sure if it will help but according to on http://www.lemis.com/grog/Papers/Debug-tutorial/tutorial.pdf the target : You choose a serial port by setting bit 0x80 of the device flags in /boot/loader.conf : hint.sio.0.flags=0x90 In this example, bit 0x10 is also set to tell the kernel gdb stub to access remote debugging via this port. Hope it helps Riaan PS. Sorry previous reply was only to Karin and not to the list as well. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: eeePC 900 turning off wireless (ath0)
On Mon, Jul 07, 2008 at 02:19:37PM +0200, Matthias Apitz wrote: /* Notify devd(8) */ device_printf(sc-dev, Fn+F2 pressed, notify to devd(8) is %08x\n, notify); acpi_UserNotify(ASUS-Eee, h, notify); and it turns out that in case of switching wireless of it is 0x0011, while on switch-on it is 0x0010; but the devd(8) only sees both events as '_SB_.ATKD'; I've grep'ed a lot around but can't see the place where the hex events of acpi_UserNotify() are converted into the string '_SB_.ATKD', any idea where to look; They are not converted, your devd.conf entries are probably wrong. Can you show again where do you get _SB_.ATKD from? -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: eeePC 900 turning off wireless (ath0)
El día Monday, July 07, 2008 a las 01:45:38PM +0100, Rui Paulo escribió:
On Mon, Jul 07, 2008 at 02:19:37PM +0200, Matthias Apitz wrote:
/* Notify devd(8) */
device_printf(sc-dev,
Fn+F2 pressed, notify to devd(8) is %08x\n, notify);
acpi_UserNotify(ASUS-Eee, h, notify);
and it turns out that in case of switching wireless of it is 0x0011,
while on switch-on it is 0x0010; but the devd(8) only sees both
events as '_SB_.ATKD'; I've grep'ed a lot around but can't see the place
where the hex events of acpi_UserNotify() are converted into the string
'_SB_.ATKD', any idea where to look;
They are not converted, your devd.conf entries are probably wrong.
Can you show again where do you get _SB_.ATKD from?
You are right! my file /usr/local/etc/devd/ath.conf for devd(8) says
now:
tify 1 {
match system ACPI;
action /usr/local/etc/devd/ath.sh $system $subsystem $notify;
};
notify 1 {
match system IFNET;
match subsystem ath0;
match typeLINK_UP;
action /usr/local/etc/devd/ath.sh $system $subsystem $type;
};
notify 1 {
match system IFNET;
match subsystem ath0;
match typeLINK_DOWN;
action /usr/local/etc/devd/ath.sh $system $subsystem $type;
};
note that in the case of IFNET you have to watch the $type to see
LINK_UP or LINK_DOWN as the events, while in ACPI you have to watch the
$notify ($type gives you _SB_.ATKD, $notify gives you 0x10 or 0x11);
thanks for the answer which let me look closer into the man page of
devd.conf;
matthias
--
Matthias Apitz
Manager Technical Support - OCLC GmbH
Gruenwalder Weg 28g - 82041 Oberhaching - Germany
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e [EMAIL PROTECTED] - w http://www.oclc.org/ http://www.UnixArea.de/
b http://gurucubano.blogspot.com/
«...una sola vez, que es cuanto basta si se trata de verdades definitivas.»
«...only once, which is enough if it has todo with definite truth.»
José Saramago, Historia del Cerca de Lisboa
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Sysinstall is still inadequate after all of these years
I have just moved to freeBSD from debian (and obviously windows before that) I also have OS X. I reinstalled OS X for my girlfriend and there is nothing to be done, it is so easy but I also don't have a clue what it does, and have no real reason to find out. The freeBSD (7.0) install I thought was fairly easy! Admitedly I did go into it assuming it was the same as debian, and if it didn't look the same well assume it is the same anyway. The only tricky part is the disk setup, but without knowing anything about slices and partitions I closed my eyes and went ahead managing to get it working (I learned about slices after). I do only have a base system installed, and I don't like installing from sysinstall. It is very slow. It didn't take too much effort to find out how the ports system works, it was just difficult determining which path to choose since there are a number of ways to update. I was really surprised when my wireless card worked, linux was a pain! Even knowing how to set it up it still requires install wireless-tools, wpa_supplicant and then making it work on boot. None of this on freeBSD. I think *BSD and linux is more for the tech savy, and if you make it too easy people assume everything is done for them and they become illiterate. David (one happy new freeBSD user) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Bug in calcru in he 6.2 and 6.3 kernels
Hello everyone, Finally found what my last problem was. We were running top in a loop and running some workloads that called sched_bind() to bind threads to specific CPUs. The problem was that (and I am using ULE) sched_bind calls a function to notify another CPU of a thread and then mi_switches out of it. Since mi_switch sets the oncpu field of the thread to NOCPU and given the thread is still running, calcru would come in and assert the fact that If I am running I better no be on NOCPU.. It appears that in other parts of the kernel (e.g. forward_signal) this is acceptable (i.e. it is okay to be running and oncpu is NOCPU). Thanks Ravi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in calcru in he 6.2 and 6.3 kernels
Murty, Ravi wrote: Hello everyone, Finally found what my last problem was. We were running top in a loop and running some workloads that called sched_bind() to bind threads to specific CPUs. The problem was that (and I am using ULE) sched_bind calls a function to notify another CPU of a thread and then mi_switches out of it. Since mi_switch sets the oncpu field of the thread to NOCPU and given the thread is still running, calcru would come in and assert the fact that If I am running I better no be on NOCPU.. It appears that in other parts of the kernel (e.g. forward_signal) this is acceptable (i.e. it is okay to be running and oncpu is NOCPU). Thanks Ravi Don't use ULE in 6.x, it's broken and will not be fixed. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: Sysinstall is still inadequate after all of these years
On Sat, Jul 5, 2008 at 7:59 AM, Mike Makonnen [EMAIL PROTECTED] wrote: Also, the installer's job should only be to install a useable system. Post-installation chores like configuration, adding/removing users, etc should be done by another application. You shouldn't need the installer once you've installed the OS. Hear, hear! To be honest, this is the only bit about the current sysinstall that I really dislike: the fact that it can be used for post-installation configuration and package installation. This causes no end of trouble for newbies, who seem to view sysinstall as The One True System Admin Tool and try to use it for configuring/installing everything. Too many times, on various BSD forums, I've had to walk people through cleaning up /etc/rc.conf and showing them how to correctly install/configure things (using standard FreeBSD tools), since they used sysinstall for everything. IMO, the installer should allow you to partition the disk(s), format the partition(s), install the OS, configure a user, and reboot the system. Anything beyond that should be handled by the OS tools, from within the installed and running OS. The tricky part will be getting the disk slicing, slice partitioning, and filesystem formatting to work reliably, with all the power of FreeBSD's GEOM modules, and ZFS. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall is still inadequate after all of these years
:... :minimalist people, while a graphical installer running on top of a :live CD, like in many Linux distributions, Ubuntu, etc. could be :envisioned. The DragonFlyBSD installer runs on top of a live CD, this is :the easiest way to have a full featured installer, but this requires a :machine with sufficient RAM. Anyways all those possibilities point to :the soundness of your propositions 1) and 2). : :-- : :Michel TALON Well, its actually more an issue of the space used on the CD, since the base system is not compressed on the media. DragonFly doesn't try to include all that many packages on its CD, so there is plenty of space. Our distribution CD's run about 300MB. There is some movement on getting a DVD distribution together and including a lot of packages on it. I think that's the way to go if a fully loaded dist is desired. The packages would be stored on the DVD as binary packages (hence compressed), but everything else would be live. As media gets larger the live portion of the distribution becomes a smaller and smaller piece of it. It's a lot easier to enhance and maintain a live distribution then it is a compressed one. Actual system memory use is tiny. Remember, only dirty data eats real memory, clean pages can simply be freed, so the the run-time footprint is not really all that large. And, frankly, anyone with a machine with 32MB of ram or less is not likely to care about direct-from-CD installs. They'd more likely be installing from a bootable USB memory stick (which runs $14 for 2G these days), or some other media. The box might not even have a CD drive, but it will certainly have USB ports. So what it comes down to is having a release build that is easy to extend and enhance, and doesn't shoot itself in the foot. You want to be able to use the same release infrastructure for all release targets. Compression of the base system creates lots and lots of unnecessary headaches. -Matt Matthew Dillon [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
Maxim Sobolev wrote: Dag-Erling Smørgrav wrote: Andrey Chernov [EMAIL PROTECTED] writes: BSD sort as an idea will be a good project indeed, but BSD sort implementation we currently have at hand is totally misleading and should be rewritten from the scratch, I realize it when long time ago I try to localize it for single byte locales. I think part of the problem is that there aren't enough people who truly understand localization. I think I understand most of it, but I'm pretty sure I *don't* understand how collation works, or is supposed to work. Amongst other things, I don't understand how (or whether) it handles cases like aa and å, which are considered the same letter in Norwegian. Perhaps you could create a Localization page on wiki.freebsd.org which addresses these issues, or at least points to relevant resources? Good regression test suite which would include cases in different single and multi-byte locates for grep/sort/etc could also be a big help. What regression suites do other implementations have? e.g. the GNU textutils. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
On Mon, Jul 07, 2008 at 10:06:31PM +0200, Kris Kennaway wrote: What regression suites do other implementations have? e.g. the GNU textutils. They basically have regex tests, but nothing locale specific, since locale ordering is different from platform to platform (until Unicode Collation Algorithm will win). -- http://ache.pp.ru/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in calcru in he 6.2 and 6.3 kernels
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kris Kennaway wrote: | Murty, Ravi wrote: | Hello everyone, | | | | Finally found what my last problem was. We were running top in a loop | and running some workloads that called sched_bind() to bind threads to | specific CPUs. The problem was that (and I am using ULE) sched_bind | calls a function to notify another CPU of a thread and then mi_switches | out of it. Since mi_switch sets the oncpu field of the thread to NOCPU | and given the thread is still running, calcru would come in and assert | the fact that If I am running I better no be on NOCPU.. It appears | that in other parts of the kernel (e.g. forward_signal) this is | acceptable (i.e. it is okay to be running and oncpu is NOCPU). | | | Thanks | Ravi | | Don't use ULE in 6.x, it's broken and will not be fixed. Perhaps we should mark it as broken using #error? After all the ULE changes in 7.x is amazing and we do not want to have users to obtain bad impressions from the 6.x versions... I am not sure but some explicit warning message saying ULE has been revamped in FreeBSD 7.x+ and will not be MFC'ed back to 6.x, please use SCHED_4BSD or upgrade to 7.x. seems to be better than having them to pursue the mailing list archive... Cheers, - -- Xin LI [EMAIL PROTECTED]http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhyfjYACgkQi+vbBBjt66CdLQCfet8ls7tfg5jV5I7gSOw8QwhC maoAn2sBwjfoOBhFt6u5fELK9X6XMp0A =Bxr3 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
Andrey Chernov wrote: On Mon, Jul 07, 2008 at 10:06:31PM +0200, Kris Kennaway wrote: What regression suites do other implementations have? e.g. the GNU textutils. They basically have regex tests, but nothing locale specific, since locale ordering is different from platform to platform (until Unicode Collation Algorithm will win). OK. Well at least it is a start - passing those existing regression tests should be a goal. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in calcru in he 6.2 and 6.3 kernels
Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kris Kennaway wrote: | Murty, Ravi wrote: | Hello everyone, | | | | Finally found what my last problem was. We were running top in a loop | and running some workloads that called sched_bind() to bind threads to | specific CPUs. The problem was that (and I am using ULE) sched_bind | calls a function to notify another CPU of a thread and then mi_switches | out of it. Since mi_switch sets the oncpu field of the thread to NOCPU | and given the thread is still running, calcru would come in and assert | the fact that If I am running I better no be on NOCPU.. It appears | that in other parts of the kernel (e.g. forward_signal) this is | acceptable (i.e. it is okay to be running and oncpu is NOCPU). | | | Thanks | Ravi | | Don't use ULE in 6.x, it's broken and will not be fixed. Perhaps we should mark it as broken using #error? After all the ULE changes in 7.x is amazing and we do not want to have users to obtain bad impressions from the 6.x versions... I am not sure but some explicit warning message saying ULE has been revamped in FreeBSD 7.x+ and will not be MFC'ed back to 6.x, please use SCHED_4BSD or upgrade to 7.x. seems to be better than having them to pursue the mailing list archive... I would agree with this; if you're happy running unstable and broken scheduler code, you're surely able to update to 7.0 and run stable and working scheduler code :) We should run it past re@ first since it's a change to a stable branch, but it's experimental code so I don't see an issue. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
Kris Kennaway escribió: Andrey Chernov wrote: On Mon, Jul 07, 2008 at 10:06:31PM +0200, Kris Kennaway wrote: What regression suites do other implementations have? e.g. the GNU textutils. They basically have regex tests, but nothing locale specific, since locale ordering is different from platform to platform (until Unicode Collation Algorithm will win). OK. Well at least it is a start - passing those existing regression tests should be a goal. Well, it seems you have missed the first nits of the discussion. GNU grep has some regression test, which doesn't pass completely itself either. :) I've mentioned here that I used those tests to find out what incompatible options are there. Unfortunately, I have to say that BSD grep won't pass all of those, because GNU allows some non-standard regexes, which are rejected by our libc-regex library, like for example (a|) is not standard because it has an empty subexpression. First, I tried to pre-edit such expression in the code. It was ugly enough but I thought: Ok, this code is pretty ugly, but compatibility is important, maybe we can later revise and/or change our regexp library and get rid of these snippets. Later, when Andrey pointed it out, I realized that my workarounds adressed those incompatibilities but didn't work completely, they broke compatibility at other places, thus I just removed them, because it was not that easy to fix. The version that I sent you for the portbuild test, doesn't have those workarounds. The regression test helped though to fix other compatibility issues, like return values. All of these trivial things are supposed to be compatible now, the only exceptions are the non-standard regexes. That's why I'm so curious about the results. If they are inacceptable, we can try to build BSD grep with the GNU regexp lib (it's in the tree, as Pedro F. Giffuni pointed it out). It doesn't work by just linking with that library, so it will need more work and investigation then, not speaking about that GNU regex should go one day... Regards, Gábor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall is still inadequate after all of these years
Hear, hear! To be honest, this is the only bit about the current sysinstall that I really dislike: the fact that it can be used for post-installation configuration and package installation. This causes no end of trouble for newbies, who seem to view sysinstall as The One True System Admin Tool and try to use it for configuring/installing everything. Too many times, on various BSD forums, I've had to walk people through cleaning up /etc/rc.conf and showing them how to correctly install/configure things (using standard FreeBSD tools), since they used sysinstall for everything. That may be true, but sysinstall did help me do basic, essentical configuration of my very first installed system, and a few installs after that (until I learned about /etc/rc.conf et al). And I never regarded it as The One True Sysadmin Tool, because I did not use Linux distros, thus never got used to their ways. It's just that the simple configuration menu really helped me to get a useful system running in a few minutes (though menu items certainly could make use of more verbose descriptions). And then I could play with the working system and learn ways to configure it. So, IMHO, a basic curses system configuration utility is still needed, and should be run after sysinstall or it should tell the user how to run it (maybe in motd, or sysinstall itself?). IMO, the installer should allow you to partition the disk(s), format the partition(s), install the OS, configure a user, and reboot the system. Anything beyond that should be handled by the OS tools, from within the installed and running OS. The tricky part will be getting the disk slicing, slice partitioning, and filesystem formatting to work reliably, with all the power of FreeBSD's GEOM modules, and ZFS. [SorAlx] ridin' VS1400 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
