9-CURRENT: ports/net/kdenetwork3 does not compile
Hello,
$ uname -a
FreeBSD tinyCurrent 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r21: Thu Oct 28
10:56:32 CEST 2010
with /usr/ports from CVS October, 30;
compiling KDE3 gives:
...
gmake[4]: Entering directory
`/usr/ports/net/kdenetwork3/work/kdenetwork-3.5.10/ktalkd/ktalkd'
c++ -DHAVE_CONFIG_H -I. -I../.. -I../../kopete/protocols/gadu/libgadu
-I/usr/local/include -I/usr/local/include -DHAVE_KDE -D_THREAD_SAFE -pthread
-DQT_THREAD_SUPPORT -I/usr/local/include -I/usr/local/include
-I/usr/local/include -D_GETOPT_H -D_THREAD_SAFE -D_LARGE_FILES=1
-Wno-long-long -Wundef -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -O2
-pipe -fno-strict-aliasing -Wno-non-virtual-dtor -fno-exceptions -fno-check-new
-fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT
-DQT_NO_TRANSLATION -MT find_user.o -MD -MP -MF .deps/find_user.Tpo -c -o
find_user.o find_user.cpp
find_user.cpp: In function 'int find_user(char*, char*, char*)':
find_user.cpp:344: error: aggregate 'utmp ubuf' has incomplete type and cannot
be defined
gmake[4]: *** [find_user.o] Error 1
The code in find_user.cpp reads:
...
#endif /*UTMP_AND_PROC_FIND_USER*/
#else /*not PROC_FIND_USER*/
int find_user(char *name, char *tty, char *disp) {
struct utmp ubuf; line 344
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);
}
Something wrong with 'struct utmp ubuf' in HEAD?
Thanks
mattihas
--
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e g...@unixarea.de - w http://www.unixarea.de/
___
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
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: 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 da...@catwhisker.org 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: 9-CURRENT: ports/net/kdenetwork3 does not compile
On Mon, Nov 1, 2010 at 23:14, Matthias Apitz g...@unixarea.de 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: 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
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: 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 j...@freebsd.org wrote:
On Monday, November 01, 2010 1:09:22 pm Giovanni Trematerra wrote:
On Tue, Oct 19, 2010 at 8:55 AM, Andriy Gapon a...@freebsd.org 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
cpu count=32 mask=0x0, 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/cpu
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 memory, just what I need to return.
Ahhh, ok. I would maybe add a comment to explain that it is ok to lose
the tmps references for this reason.
Hmm, one problem I see is that if you need to allocate 4 pages and only 3
are available, you will fail with 'tmps =
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 Tue, Nov 2, 2010 at 2:11 PM, Andriy Gapon a...@freebsd.org 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: 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 Starting AP scan (broadcast SSID)
Re: wpa_supplicant gets points for trying, I suppose....
On Tue, Nov 2, 2010 at 16:53, David Wolfskill da...@catwhisker.org 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 2, 2010 at 10:30 AM, Bernhard Schmidt bschm...@freebsd.org wrote: On Tue, Nov 2, 2010 at 16:53, David Wolfskill da...@catwhisker.org 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 19:06, Garrett Cooper gcoo...@freebsd.org wrote: On Tue, Nov 2, 2010 at 10:30 AM, Bernhard Schmidt bschm...@freebsd.org wrote: On Tue, Nov 2, 2010 at 16:53, David Wolfskill da...@catwhisker.org 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: 9-CURRENT: ports/net/kdenetwork3 does not compile
On Tue, Nov 2, 2010 at 11:38, David DEMELIER demelier.da...@gmail.com 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: 9-CURRENT: ports/net/kdenetwork3 does not compile
2010/11/2 Rob Farmer rfar...@predatorlabs.net: On Mon, Nov 1, 2010 at 23:14, Matthias Apitz g...@unixarea.de 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
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
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 e...@80386.nl
WWW: http://80386.nl/
--- ktalkd/ktalkd/find_user.cpp
+++ ktalkd/ktalkd/find_user.cpp
@@ -339,34 +339,33 @@
#else /*not PROC_FIND_USER*/
+#include utmpx.h
+
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
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: 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: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: 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 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: 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: psm(4) - synaptics touch pad strange behavier
On Tue, 02 Nov 2010 22:02:17 +0100
Jean-Sébastien Pédron dumbb...@freebsd.org 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
