Re: psm(4) - synaptics touch pad strange behavier
On Tue, 02 Nov 2010 22:02:17 +0100 Jean-Sébastien Pédron wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi! > > On 26.09.2010 17:44, Norikatsu Shigemura wrote: > > Hi psm(4) masters! > > > > I have trouble using Synaptics TouchPad, psm(4) on my CF-R9. > > The trouble is that the mouse cursor moves at random, and > > the mouse button is clicked without button action. I heard same > > trouble from ume@'s CF-R8. > > > > So I enabled options PSM_DEBUG=5 and traced psm's packets. > > My Synaptics touchpad was going back to "Relative Mode" after > initialization (enable_synaptics) and I never identified the reason. I > think yours is suffering from the same behaviour. > This may or may not be helpful, so my apologies if I'm up the wrong tree. I'm not sure if the CF-R{8,9} share the same touchpad. I have a CF-19k and my Synaptics pad was never recognised as such, so a while ago I attempted to hack the psm(4) code to force it. I was able to force it and change from abs to relative (or maybe the other way, I forget), but when I did I had similar problems with a cursor moving at random. Is your touchpad a Fujitsu touchscreen/touchpad (FJC6001 - I think) like the CF19? If so I believe Linux have a Fujitsu Lifebook touchscreen/touchpad driver that treats the device as two different units, touchpad & touchscreen (I believe the hardware appears only as one device but has two outputs). Unfortunately, the touchpad side of things appears to be a plain ps/2 device without Synaptics capabilities (the hardware/programming spec was out on the Internet at some point). However, with very minimal effort I think the touchscreen could be enabled via psm(4). I have not been able to try it as my CF19 has the Wacom touchscreen (which doesn't work on CURRENT :( ), but it still retains the full Fujitsu touchscreen/touchpad device. HTH, if not good luck and sorry for the wasted bandwidth. Rob ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: wpa_supplicant gets points for trying, I suppose....
On Tue, Nov 02, 2010 at 06:30:10PM +0100, Bernhard Schmidt wrote: > > Thanks. I had quick look into that and I currently do not see an easy > way to address that issue, as in tell wpa_supplicant about the device's > state. This might change though once a newer wpa_supplicant has been > imported. I'm not entirely surprised -- a quick look I took at sys/dev/iwn seemed to indicate to me that whiule iwn(4) could whine about the switch, it didn't have much in the way of ability to actually provide information about that status in some other way (e.g., a non-zero return from attempt to mess with the device). But I don't claim extensive expertise in that area. > For now just add wpa_supplicant_flags="-" to rc.conf. :-} That, or decide to ignore the silly messages Noted, thanks. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpUWaGmedrbL.pgp Description: PGP signature
Re: Corruption of UFS filesystems after using md(4)
On 11/02/2010 20:37, Bruce Cran wrote: > On Tuesday 02 November 2010 19:57:32 Kostik Belousov wrote: > >> What is .viminfo ? How is it related to the command you have shown ? >> What are exact mount options you are using ? > > .viminfo is a file created by vim containing various bits of session > information. I don't know why it gets corrupted, but I guess it's the way > it's > created. I've seen other dot files get corrupted in the past too though. Chances are it's reusing the inode that was used for the sparse file. Cheers, -- Thomas E. Spanjaard t...@netphreax.net t...@deepbone.net signature.asc Description: OpenPGP digital signature
Re: psm(4) - synaptics touch pad strange behavier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! On 26.09.2010 17:44, Norikatsu Shigemura wrote: > Hi psm(4) masters! > > I have trouble using Synaptics TouchPad, psm(4) on my CF-R9. > The trouble is that the mouse cursor moves at random, and the > mouse button is clicked without button action. I heard same > trouble from ume@'s CF-R8. > > So I enabled options PSM_DEBUG=5 and traced psm's packets. My Synaptics touchpad was going back to "Relative Mode" after initialization (enable_synaptics) and I never identified the reason. I think yours is suffering from the same behaviour. To work around this, I added a hack at the beginning of doopen() in psm.c but looking at your log, it's never executed (you should see "psm0: Synaptis Absolute Mode hopefully restored"). I think my check on line 886 in psm.c (on -CURRENT) isn't right: if (stat[1] == 0x47 && stat[2] == 0x40) { Could you please try to change this line to: if (stat[1] == 0x47) { (ie. remove the second test) stat[2] contains the value of the "Mode Byte". 0x40 means "Relative Mode with high packet rate". Maybe yours is going back to "Relative Mode" only (0x00); see top of p.35 of the Interfacing Guide. A better test would be to look at the "Absolute Mode" bit only (or no test at all, like the change I propose). I can't test this myself because my laptop with the Synaptics touchpad died. - -- Jean-Sébastien Pédron -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzQfFkACgkQa+xGJsFYOlNYcACeM0/JYaYCx4CZHiWOZyi/pTaS lmoAoJLzYwlVn4ANpdoL+n99XOKzLWjv =AXjv -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Corruption of UFS filesystems after using md(4)
On Tuesday 02 November 2010 19:57:32 Kostik Belousov wrote: > What is .viminfo ? How is it related to the command you have shown ? > What are exact mount options you are using ? .viminfo is a file created by vim containing various bits of session information. I don't know why it gets corrupted, but I guess it's the way it's created. I've seen other dot files get corrupted in the past too though. /usr is mounted as: /dev/ada0s1f on /usr (ufs, local, soft-updates) Its entry in /etc/fstab is: /dev/ada0s1f/usrufs rw 2 2 It's a totally standard installation from a HEAD snapshot which is now running r214509. I've now seen the problem on a xen VPS, a desktop and a laptop. -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Corruption of UFS filesystems after using md(4)
On Tue, Nov 02, 2010 at 07:33:50PM +, Bruce Cran wrote: > On Tuesday 02 November 2010 19:12:14 Bruce Cran wrote: > > I've noticed in recent months that I appear to be getting silent corruption > > of my UFS filesystems - and I think it may be linked to using md(4) or > > creating sparse files. > > I've confirmed this is a UFS bug related to sparse files: "truncate -s20G f1 > && rm f1" is enough to trigger the error and start generating .viminfo files > that appear to be 20GB. When running fsck I get an "Invalid block count" > error > if I just reboot without removing the .viminfo file; if I do remove it, I get > a "Partially allocated inode" error. What is .viminfo ? How is it related to the command you have shown ? What are exact mount options you are using ? pgptWUg6pqlsN.pgp Description: PGP signature
Re: Corruption of UFS filesystems after using md(4)
On Tuesday 02 November 2010 19:12:14 Bruce Cran wrote: > I've noticed in recent months that I appear to be getting silent corruption > of my UFS filesystems - and I think it may be linked to using md(4) or > creating sparse files. I've confirmed this is a UFS bug related to sparse files: "truncate -s20G f1 && rm f1" is enough to trigger the error and start generating .viminfo files that appear to be 20GB. When running fsck I get an "Invalid block count" error if I just reboot without removing the .viminfo file; if I do remove it, I get a "Partially allocated inode" error. -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9-CURRENT: ports/net/kdenetwork3 does not compile
Hello all, Just to notify everyone what's going on; Matthias tested a patch for me, which should make it work on HEAD again. The attached patch should be applied to the sources conditionally (so only when running HEAD). I am in the process of getting it fixed in ports/upstreamed. Greetings, -- Ed Schouten WWW: http://80386.nl/ --- ktalkd/ktalkd/find_user.cpp +++ ktalkd/ktalkd/find_user.cpp @@ -339,34 +339,33 @@ #else /*not PROC_FIND_USER*/ +#include + int find_user(char *name, char *tty, char *disp) { -struct utmp ubuf; +struct utmpx *ubuf; int status; -FILE *fd; struct stat statb; -char ftty[20+UT_LINESIZE]; -char ttyFound[UT_LINESIZE] = ""; -char dispFound[UT_HOSTSIZE+1] = ""; - -if (!(fd = fopen(_PATH_UTMP, "r"))) { -fprintf(stderr, "talkd: can't read %s.\n", _PATH_UTMP); -return (FAILED); -} +char ftty[20 + sizeof ubuf->ut_line]; +char ttyFound[sizeof ubuf->ut_line] = ""; +char dispFound[sizeof ubuf->ut_line + 1] = ""; + +setutxent(); #define SCMPN(a, b)strncmp(a, b, sizeof (a)) status = NOT_HERE; (void) strcpy(ftty, _PATH_DEV); -while (fread((char *) &ubuf, sizeof ubuf, 1, fd) == 1) { -if (!SCMPN(ubuf.ut_name, name)) { +while ((ubuf = getutxent())) { +if ((ubuf->ut_type == USER_PROCESS) && +(!SCMPN(ubuf->ut_user, name))) { if (*tty == '\0') { /* no particular tty was requested */ -(void) strcpy(ftty+5, ubuf.ut_line); +(void) strcpy(ftty+5, ubuf->ut_line); if (stat(ftty,&statb) == 0) { if (!(statb.st_mode & 020)) /* ?character device? */ continue; -(void) strcpy(ttyFound, ubuf.ut_line); +(void) strcpy(ttyFound, ubuf->ut_line); #ifdef USE_UT_HOST -(void) strcpy(dispFound, ubuf.ut_host); +(void) strcpy(dispFound, ubuf->ut_host); strcat(dispFound, " "); #endif status = SUCCESS; @@ -384,13 +383,13 @@ } } } - else if (!strcmp(ubuf.ut_line, tty)) { + else if (!strcmp(ubuf->ut_line, tty)) { status = SUCCESS; break; } } } -fclose(fd); +endutxent(); if (status == SUCCESS) { (void) strcpy(tty, ttyFound); (void) strcpy(disp, dispFound); pgpHdoKZt6XfX.pgp Description: PGP signature
Corruption of UFS filesystems after using md(4)
I've noticed in recent months that I appear to be getting silent corruption of my UFS filesystems - and I think it may be linked to using md(4) or creating sparse files. I created a 20GB md device using "truncate -s 20G mdfile && mdconfig -a -f mdfile" and then ran some gpart commands before using "mdconfig -d -u 0" and rm'ing the file. Some time later I noticed the following had been logged to dmesg: free inode /usr/3367984 had 128 blocks free inode /usr/3367984 had 32 blocks Now, whenever I run vim it creates a sparse 20GB .viminfo file - on another server those files were reported as being 8TB. I've disabled background fsck so the filesystems should have been clean when the system booted, and I'm not using SU+J. -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9-CURRENT: ports/net/kdenetwork3 does not compile
2010/11/2 Rob Farmer : > On Mon, Nov 1, 2010 at 23:14, Matthias Apitz wrote: >> Something wrong with 'struct utmp ubuf' in HEAD? > > It has been removed: > > http://lists.freebsd.org/pipermail/freebsd-current/2010-January/014893.html > > -- > Rob Farmer > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > A lot of ports will need some patches then, isn't it ? -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9-CURRENT: ports/net/kdenetwork3 does not compile
On Tue, Nov 2, 2010 at 11:38, David DEMELIER wrote: > A lot of ports will need some patches then, isn't it ? Most were taken care of back when it happened - many either included utmp.h and never used it or only used it trivially, so it was easy to fix (I submitted patches for some and I'm definitely not a great programmer). So the fact that it wasn't fixed either means nobody cares about that port (somewhat true here - most of the KDE people moved on to 4) or that the fix will be more involved (probably the case for this one). -- Rob Farmer ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: wpa_supplicant gets points for trying, I suppose....
On Tue, Nov 2, 2010 at 19:06, Garrett Cooper wrote: > On Tue, Nov 2, 2010 at 10:30 AM, Bernhard Schmidt > wrote: >> On Tue, Nov 2, 2010 at 16:53, David Wolfskill wrote: >>> On Tue, Nov 02, 2010 at 08:40:54AM +0100, Bernhard Schmidt wrote: > > I have the switch on this laptop in position to disable the wireless > > device (iwn(4)). Is there some way wpa_supplicant (or something) might > > be able to recognize that this is a pointless exercise? > > Well iwn could bring device down when radio is turned off and > bring it up when radio is turned on ??? Well, that should actually be the case. I don't see how it might differ between stable/8 and head. Can you post the output of wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -d while the RF kill button is in disabled state? > > I don't recall stable/8 doing this, though I could be wrong. >>> >>> Next time I booted stable/8, I checked /var/log/messages, and verified >>> that wpa_supplicant is also persistent in that environment. >>> >>> So I did the above within script(1); I've attached a copy of the >>> typescript file. This was done while running: >>> >>> FreeBSD 8.1-STABLE #20 r214672: Tue Nov 2 04:19:13 PDT 2010 >> >> Thanks. I had quick look into that and I currently do not see an easy >> way to address that issue, as in tell wpa_supplicant about the device's >> state. This might change though once a newer wpa_supplicant has been >> imported. >> >> For now just add wpa_supplicant_flags="-" to rc.conf. > > Device states could and should be periodically polled via the > SIOCGIFMEDIA ioctl, but currently isn't (even in the CURRENT version > of wpa_supplicant). This seems like a worthy enhancement. Not necessarily, we have a event based facility for that, the functions are empty though because the consumer, wpa_supplicant, is not able to make any use of it. There were some changes in 0.7 for interface states but I'm not sure what exactly changed, it might be possible to use events for the 'rfkill on' case, the 'rfkill off' might still need polling.. Once Rui has imported the new wpa stuff, someone should implemented the proper calls :) -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: wpa_supplicant gets points for trying, I suppose....
On Tue, Nov 2, 2010 at 10:30 AM, Bernhard Schmidt wrote: > On Tue, Nov 2, 2010 at 16:53, David Wolfskill wrote: >> On Tue, Nov 02, 2010 at 08:40:54AM +0100, Bernhard Schmidt wrote: >>> >>> > > I have the switch on this laptop in position to disable the wireless >>> > > device (iwn(4)). Is there some way wpa_supplicant (or something) might >>> > > be able to recognize that this is a pointless exercise? >>> > >>> > Well iwn could bring device down when radio is turned off and >>> > bring it up when radio is turned on ??? >>> >>> Well, that should actually be the case. I don't see how it might differ >>> between stable/8 and head. >>> >>> Can you post the output of >>> wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -d >>> while the RF kill button is in disabled state? >>> >>> > > I don't recall stable/8 doing this, though I could be wrong. >> >> Next time I booted stable/8, I checked /var/log/messages, and verified >> that wpa_supplicant is also persistent in that environment. >> >> So I did the above within script(1); I've attached a copy of the >> typescript file. This was done while running: >> >> FreeBSD 8.1-STABLE #20 r214672: Tue Nov 2 04:19:13 PDT 2010 > > Thanks. I had quick look into that and I currently do not see an easy > way to address that issue, as in tell wpa_supplicant about the device's > state. This might change though once a newer wpa_supplicant has been > imported. > > For now just add wpa_supplicant_flags="-" to rc.conf. Device states could and should be periodically polled via the SIOCGIFMEDIA ioctl, but currently isn't (even in the CURRENT version of wpa_supplicant). This seems like a worthy enhancement. Cheers, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: wpa_supplicant gets points for trying, I suppose....
On Tue, Nov 2, 2010 at 16:53, David Wolfskill wrote: > On Tue, Nov 02, 2010 at 08:40:54AM +0100, Bernhard Schmidt wrote: >> >> > > I have the switch on this laptop in position to disable the wireless >> > > device (iwn(4)). Is there some way wpa_supplicant (or something) might >> > > be able to recognize that this is a pointless exercise? >> > >> > Well iwn could bring device down when radio is turned off and >> > bring it up when radio is turned on ??? >> >> Well, that should actually be the case. I don't see how it might differ >> between stable/8 and head. >> >> Can you post the output of >> wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -d >> while the RF kill button is in disabled state? >> >> > > I don't recall stable/8 doing this, though I could be wrong. > > Next time I booted stable/8, I checked /var/log/messages, and verified > that wpa_supplicant is also persistent in that environment. > > So I did the above within script(1); I've attached a copy of the > typescript file. This was done while running: > > FreeBSD 8.1-STABLE #20 r214672: Tue Nov 2 04:19:13 PDT 2010 Thanks. I had quick look into that and I currently do not see an easy way to address that issue, as in tell wpa_supplicant about the device's state. This might change though once a newer wpa_supplicant has been imported. For now just add wpa_supplicant_flags="-" to rc.conf. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: wpa_supplicant gets points for trying, I suppose....
On Tue, Nov 02, 2010 at 08:40:54AM +0100, Bernhard Schmidt wrote: > > > > I have the switch on this laptop in position to disable the wireless > > > device (iwn(4)). Is there some way wpa_supplicant (or something) might > > > be able to recognize that this is a pointless exercise? > > > > Well iwn could bring device down when radio is turned off and > > bring it up when radio is turned on ??? > > Well, that should actually be the case. I don't see how it might differ > between stable/8 and head. > > Can you post the output of > wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -d > while the RF kill button is in disabled state? > > > > I don't recall stable/8 doing this, though I could be wrong. Next time I booted stable/8, I checked /var/log/messages, and verified that wpa_supplicant is also persistent in that environment. So I did the above within script(1); I've attached a copy of the typescript file. This was done while running: FreeBSD 8.1-STABLE #20 r214672: Tue Nov 2 04:19:13 PDT 2010 Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. Script started on Tue Nov 2 08:45:28 2010 d130# ps axwwl | grep wpa_s 0 3528 3523 0 45 0 3500 1240 piperd S+180:00.01 grep wpa_s d130# wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -d Initializing interface 'wlan0' conf '/etc/wpa_supplicant.conf' driver 'bsd' ctrl_interface 'N/A' bridge 'N/A' Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf' Reading configuration file '/etc/wpa_supplicant.conf' Priority group 93 id=17 ssid='lmdhw-net' id=18 ssid='lmdhw-net' Priority group 85 id=19 ssid='NETGEAR' id=20 ssid='wifi' Priority group 17 id=0 ssid='DojoTest' Priority group 16 id=1 ssid='HackerDojoDownstairs' id=2 ssid='HackerDojoUpstairs' id=3 ssid='LINKEDIN-GUEST' id=4 ssid='LINKEDIN-GUEST' id=5 ssid='LINKEDIN-GUEST' id=6 ssid='LINKEDIN-GUEST' id=7 ssid='LINKEDIN-GUEST' id=8 ssid='LINKEDIN-GUEST' id=9 ssid='LINKEDIN-GUEST' id=10 ssid='LINKEDIN-GUEST' id=11 ssid='LINKEDIN-GUEST' id=12 ssid='LINKEDIN-GUEST' id=13 ssid='LINKEDIN-GUEST' id=14 ssid='LINKEDIN-GUEST' id=15 ssid='LINKEDIN-GUEST' id=16 ssid='LINKEDIN-GUEST' Initializing interface (2) 'wlan0' Own MAC address: 00:21:6a:26:34:c0 wpa_driver_bsd_set_wpa: enabled=1 wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1 wpa_driver_bsd_del_key: keyidx=0 wpa_driver_bsd_del_key: keyidx=1 wpa_driver_bsd_del_key: keyidx=2 wpa_driver_bsd_del_key: keyidx=3 wpa_driver_bsd_set_countermeasures: enabled=0 wpa_driver_bsd_set_drop_unencrypted: enabled=1 RSN: flushing PMKID list in the driver Setting scan request: 0 sec 10 usec EAPOL: SUPP_PAE entering state DISCONNECTED EAPOL: KEY_RX entering state NO_KEY_RECEIVE EAPOL: SUPP_BE entering state INITIALIZE EAP: EAP entering state DISABLED Added interface wlan0 State: DISCONNECTED -> SCANNING Starting AP scan (broadcast SSID) Trying to get current scan results first without requesting a new scan to speed up initial association Received 0 bytes of scan results (0 BSSes) Scan results: 0 Cached scan results are empty - not posting Selecting BSS from priority group 93 Try to find WPA-enabled AP Try to find non-WPA AP Selecting BSS from priority group 85 Try to find WPA-enabled AP Try to find non-WPA AP Selecting BSS from priority group 17 Try to find WPA-enabled AP Try to find non-WPA AP Selecting BSS from priority group 16 Try to find WPA-enabled AP Try to find non-WPA AP No suitable AP found. Setting scan request: 0 sec 0 usec Starting AP scan (broadcast SSID) ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. Setting scan request: 10 sec 0 usec EAPOL: disable timer tick Starting AP scan (broadcast SSID) ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. Setting scan request: 10 sec 0 usec Starting AP scan (broadcast SSID) ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. Setting scan request: 10 sec 0 usec Starting AP scan (broadcast SSID) ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. Setting scan request: 10 sec 0 usec Starting AP scan (broadcast SSID) ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. Setting scan request: 10 sec 0 usec Starting AP scan (broadcast SSID) ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. Setting scan request: 10 sec 0 usec Starting AP scan (broadcast SSID) ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. Setting scan request: 10 sec 0 usec Starting AP scan (broadcast SSID) ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. Setting scan request: 10 sec 0 usec Start
Re: panic in uma_startup for many-core amd64 system
On Tue, Nov 2, 2010 at 2:11 PM, Andriy Gapon wrote: > on 01/11/2010 19:09 Giovanni Trematerra said the following: >> Here the patch that was in my mind. >> The patch doesn't implement dynamic slab size just allow >> to have a multipage slab to back uma_zone objects. >> I'm going to work more on the topic "dynamic slab size" soon. >> I tested the patch on qemu with -smp 32. >> I'm looking for real hw to test the patch on. > > Having only skimmed the patch I have a question - is this only used for > internal > zones? "Application" zones with large items still use off-page slabs? > Yes, it is used only for internal zones. Other zones will go off-page as usual. -- Giovanni Trematerra ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic in uma_startup for many-core amd64 system
on 01/11/2010 19:09 Giovanni Trematerra said the following: > Here the patch that was in my mind. > The patch doesn't implement dynamic slab size just allow > to have a multipage slab to back uma_zone objects. > I'm going to work more on the topic "dynamic slab size" soon. > I tested the patch on qemu with -smp 32. > I'm looking for real hw to test the patch on. Having only skimmed the patch I have a question - is this only used for internal zones? "Application" zones with large items still use off-page slabs? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic in uma_startup for many-core amd64 system
On Monday, November 01, 2010 6:02:19 pm Giovanni Trematerra wrote: > On Mon, Nov 1, 2010 at 8:14 PM, John Baldwin wrote: > > On Monday, November 01, 2010 1:09:22 pm Giovanni Trematerra wrote: > >> On Tue, Oct 19, 2010 at 8:55 AM, Andriy Gapon wrote: > >> > on 19/10/2010 00:01 Giovanni Trematerra said the following: > >> >> > >> >> Your patch seems just a work around about initial slab size where the > >> >> keg is backed. > >> > > >> > Well, setting aside my confusion with the terminology - yes, the patch is > > just > >> > that, and precisely because I only tried to solve that particular > >> > problem. > >> > > >> >> Having dynamic slab sizes would allow to have the keg backed on a larger > > slab > >> >> without going OFFPAGE. > >> > > >> > I agree in principle. > >> > But without seeing code that implements that I can't guess if it would > > really be > >> > more efficient or more maintainable, i.e. more useful in general. > >> > Still a very good idea. > >> > > >> > >> Here the patch that was in my mind. > >> The patch doesn't implement dynamic slab size just allow > >> to have a multipage slab to back uma_zone objects. > >> I'm going to work more on the topic "dynamic slab size" soon. > >> I tested the patch on qemu with -smp 32. > >> I'm looking for real hw to test the patch on. > >> > >> here some interesting output: > >> qemulab# vmstat -z | more > >> ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP > >> > >> UMA Kegs: 208, 0, 149, 4, 149, 0, 0 > >> UMA Zones: 4480, 0, 149, 0, 149, 0, 0 > >> UMA Slabs: 568, 0, 836, 4,1187, 0, 0 > >> UMA RCntSlabs: 568, 0, 202, 1, 202, 0, 0 > >> UMA Hash: 256, 0, 2, 13, 3, 0, 0 > >> > >> qemulab# sysctl kern | grep cpu > >> kern.ccpu: 0 > >> 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, > >> 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, > >> 28, 29, 30, 31 > >> kern.smp.cpus: 32 > >> kern.smp.maxcpus: 32 > >> > >> Any feedback will be appreciate. > >> > >> -- > >> Giovanni Trematerra > >> > >> > >> == > >> diff -r 36572cbc6817 sys/vm/uma_core.c > >> --- a/sys/vm/uma_core.c Tue Oct 05 04:49:04 2010 -0400 > >> +++ b/sys/vm/uma_core.c Mon Nov 01 11:54:38 2010 -0400 > >> @@ -930,27 +930,36 @@ startup_alloc(uma_zone_t zone, int bytes > >> { > >> uma_keg_t keg; > >> uma_slab_t tmps; > >> - > >> - keg = zone_first_keg(zone); > >> + u_int16_t pages; > >> + > >> + keg = zone_first_keg(zone); > >> + pages = bytes / PAGE_SIZE; > >> + > >> + /* Account for remainder */ > >> + if ((pages * PAGE_SIZE) < bytes) > >> + pages++; > >> + KASSERT(pages > 0, ("startup_alloc can't reserve 0 pages\n")); > > > > You can use 'pages = howmany(bytes, PAGE_SIZE)' here. > > Thanks for the hint. > > > Also, why did you make > > pages a uint16_t instead of an int? An int is generally more convenient > > unless you really need a uint16_t (and C99 spells it without an _ after the > > leading 'u'.. FYI). > > Uhm just to be coherent with field uk_ppera of struct keg, but I think > I can just use an int. > BTW is new code supposed to use C99 form even if the rest of the file > use u_int* form? Hmm, if it is matching existing code that is ok I guess. I do use the C99 names for all new code personally. > > Probably best to make the pages test here explicit. Also, is there any > > reason > > you can't do this as: > > > >while (--pages > 0) { > >tmps = LIST_FIRST(&uma_boot_pages); > >if (tmps != NULL) > >LIST_REMOVE(tmps, us_link); > >else if (booted == 0) > >panic(...); > >} > > > > Well, no, even if I'll need to initialize tmps to NULL otherwise the > compiler will > raise a warning. > do {} while(); might be still better than a while(){}. bytes parameter > will never be > zero so pages will always be at least one and KASSERT will catch some > wired behavior. > Anyway that looks to me more readable, thanks. I could add an "else > break;" just in > the few cases that "pages" is still > 0 and tmps == NULL, that could > be useless though. It is probably best to add the break. You can still use a do {} while to fix the compiler warning though, that's a legitimate reason. :) > > One question btw, how does this work since if you need to allocate more > > than 1 > > page it seems that the 'tmps' values for all but the last are simply ignored > > and leaked? > > When you extract one item from the list you have tmps->us_data > pointing to start address of the memory page. The pages are contiguous > in decrescent > order of address (see below) so when you extract 2 items the last one > will point at > the start address of 2 contiguous pages of memo
net.link.log_link_state_change broken?
Hi, It appears we do not log such events anymore (at least with wlan devices) in console. I set this sysctl to 0 via sysctl.conf, if I set it to 1, nothing will change. Because I had loging disabled for very long time I encountered this problem just now. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: multiple problems between r212316 and r212643 on ia64
On Thu, Oct 21, 2010 at 09:44:58PM -0700, Marcel Moolenaar wrote: > > On Sep 16, 2010, at 3:57 AM, Anton Shterenlikht wrote: > >>> > >>> % man ls > >>> zcat: /usr/share/man/cat1/ls.1.gz already has .gz suffix -- unchanged > >>> % man man > >>> zcat: /usr/share/man/cat1/man.1.gz already has .gz suffix -- unchanged > >>> > >>> # cd /etc/mail > >>> # make start > >>> Starting: sendmail-submitmailwrapper: no mapping in /etc/mail/mailer.conf > >>> sendmail-clientmqueuemailwrapper: no mapping in /etc/mail/mailer.conf > >>> . > >>> # > >>> > >>> # cd /usr/src > >>> # svn up > >>> svn: Can't open file '/usr/local/etc/subversion/servers': Illegal byte > >>> sequence > >>> # > >>> > > This is now fixed (revision 214194). Yes, I've got r214196 and r214621 working fine on 2 different boxes. many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9-CURRENT: ports/net/kdenetwork3 does not compile
On Mon, Nov 1, 2010 at 23:14, Matthias Apitz wrote: > Something wrong with 'struct utmp ubuf' in HEAD? It has been removed: http://lists.freebsd.org/pipermail/freebsd-current/2010-January/014893.html -- Rob Farmer ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: wpa_supplicant gets points for trying, I suppose....
On Monday, November 01, 2010 23:32:49 Paul B Mahol wrote: > On 11/1/10, David Wolfskill wrote: > > FreeBSD 9.0-CURRENT #31 r214621M > > > > Nov 1 15:09:40 d130 wpa_supplicant[569]: Failed to initiate AP scan. > > Nov 1 15:10:10 d130 last message repeated 3 times > > Nov 1 15:10:50 d130 last message repeated 4 times > > ... > > Nov 1 15:11:00 d130 wpa_supplicant[569]: Failed to initiate AP scan. > > Nov 1 15:11:10 d130 wpa_supplicant[569]: Failed to initiate AP scan. > > ... > > Nov 1 15:11:20 d130 wpa_supplicant[569]: Failed to initiate AP scan. > > Nov 1 15:11:30 d130 wpa_supplicant[569]: Failed to initiate AP scan. > > ... > > Nov 1 15:11:40 d130 wpa_supplicant[569]: Failed to initiate AP scan. > > ... > > Nov 1 15:11:50 d130 wpa_supplicant[569]: Failed to initiate AP scan. > > Nov 1 15:12:10 d130 last message repeated 2 times > > Nov 1 15:14:10 d130 last message repeated 12 times > > > > I have the switch on this laptop in position to disable the wireless > > device (iwn(4)). Is there some way wpa_supplicant (or something) might > > be able to recognize that this is a pointless exercise? > > Well iwn could bring device down when radio is turned off and > bring it up when radio is turned on ??? Well, that should actually be the case. I don't see how it might differ between stable/8 and head. Can you post the output of wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -d while the RF kill button is in disabled state? > > I don't recall stable/8 doing this, though I could be wrong. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: serious issue caused by usb device, stalling almost all operations
On Monday 01 November 2010 15:38:38 Alexander Best wrote: > On Mon Oct 25 10, Alexander Motin wrote: > > Hans Petter Selasky wrote: > > > On Wednesday 20 October 2010 17:30:40 Alexander Best wrote: > > >> hi there, > > >> > > >> i'm running HEAD (r213495; amd64). i stumbled upon this severe > > >> problem: > > >> > > >> after attaching my mobile phone, it simply resets without doing mount > > >> or anything. however after letting the device come up again it won't > > >> show up in the console. after detaching it the usb subsystem seemed > > >> to have completely crashed. but that's not all. the following > > >> programs now simply hang without producing any output C-C won't do > > >> anything: > > >> > > >> - dmesg > > >> - top > > >> - ps > > >> - killall > > >> - camcontrol devlist > > >> - usbconfig > > > > > > That's most likely because USB's umass driver is waiting for cam to > > > drain. Possibly some refcounting is not correct. I suspect this is not > > > a USB problem. Try to enter into the debugger, and look for backtrace > > > for function stuck in umass_detach. > > i set debug.kdb.panic=1, but didn't work, because writing the core dump > stalled and watchdog came up. > Maybe you could manually run: bt all And look for "cam" and "usb" keywords. And write down the backtraces. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Monday 01 November 2010 22:14:49 John Baldwin wrote: > On Monday, November 01, 2010 3:54:59 pm Hans Petter Selasky wrote: > > Hi! > > > > I've wrapped up an outline patch for what needs to be done to integrate > > the USB process framework into the kernel taskqueue system in a more > > direct way that to wrap it. > > > > The limitation of the existing taskqueue system is that it only > > guarantees execution at a given priority level. USB requires more. USB > > also requires a guarantee that the last task queued task also gets > > executed last. This is for example so that a deferred USB detach event > > does not happen before any pending deferred I/O for example in case of > > multiple occurring events. > > > > Mostly this new feature is targeted for GPIO-alike system using slow > > busses like the USB. Typical use case: > > > > 2 tasks to program GPIO on. > > 2 tasks to program GPIO off. > > > > Example: > > > > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- > > > > >sc_task_on[1]); > > > > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- > > > > >sc_task_off[1]); > > > > No matter how the call ordering of code-line a) and b), we are always > > guaranteed that the last queued state "on" or "off" is reached before the > > head of the taskqueue empties. > > > > > > In lack of a better name, the new function was called > > taskqueue_enqueue_odd [some people obviously think that USB processes > > are odd, but not taskqueues > > > > :-)] > > It feels like this should be something you could manage with a state > machine internal to USB rather than forcing that state into the taskqueue > code itself. Hi John, No, this is not possible without keeping my own queue, which I want to avoid. By state-machine you mean remembering the last state as a separate variable and checking that in the task-callback, right? Yes, I do that in addition to the new queuing mechanism. A task barrier does not solve my problem. The barrier in my case is always last in the queue. I need to pull out previously queued tasks and put them last. That is currently not supported. I do this because I don't want to have a FIFO signalling model, and a neither want the pure taskqueue, which only ensures execution, not order of execution when at the same priority. Another issue: Won't the barrier model lead to blocking the caller once the task in question is being issued the second time? --HPS > If you wanted a simple barrier task (where a barrier task is > always queued at the tail of the list and all subsequent tasks are queued > after the barrier task) then I would be fine with adding that. You could > manage this without having to alter the task KBI by having the taskqueue > maintain a separate pointer to the current "barrier" task and always > enqueue entries after that task (the barrier would be NULL before a > barrier is queued, and set to NULL when a barrier executes). > > I think this sort of semantic is a bit simpler and also used in other parts > of the tree (e.g. in bio queues). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"