Re: [RFC] More meaningful information about ENOEXEC for kldload(8)
On 10/25/2010 5:53 PM, Garrett Cooper wrote: On Mon, Oct 25, 2010 at 2:15 PM, Doug Bartondo...@freebsd.org wrote: On 10/25/2010 13:33, Ivan Voras wrote: (except if the message is changed to say please look at the kernel syslog messages to find out the real reason for this failure) Thinking about Garrett's response as well, this may be the best way to go. Well.. I'm not saying the current output is the best, but I just don't want to dig a deeper hole that will further confuse people, as some users may get even more confused with additional details. I don't think You'll find more information in the logs to be confusing. At this point I'm also not concerned about waiting for an ideal solution. IMO an incremental change here would be most welcome. Wouldn't noting this in the manpage be sufficient? I think _also_ adding it to the man page would be appropriate. IMO this is an area where we have to try and think more like users, and less like developers. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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] More meaningful information about ENOEXEC for kldload(8)
On 10/26/10 02:53, Garrett Cooper wrote: Wouldn't noting this in the manpage be sufficient? I ran into this `item' (:)..) today after a power outage because nvidia-driver was built against different kernel headers, and it prints out the error clear as day on /dev/console, Luckily in your case, it happened *before* starting X :) ___ 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: Broadcom BCM4310 USB Controller (Wifi)
On Mon, Oct 25, 2010 at 1:07 AM, Matthias Apitz g...@unixarea.de wrote: I have a new laptop Acer Aspire One D250 and pulled out HEAD from SVN today morning. As far as I can see in sys/dev/bwi and sys/dev/bwn the above chip is still not supported. I am wrong? i have the same problem with a BCM43225. there is a linux driver: is anyone going to port it in the near future? would a donation help the process? Any other idea how to get Wifi working on this mini laptop? i've tried ndis without success... -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ 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] More meaningful information about ENOEXEC for kldload(8)
On Monday, October 25, 2010 3:19:26 pm Xin LI wrote: Hi, Here is a simple patch that adds more meaning messages when kldload hits ENOEXEC. Before patch: kldload: can't load geom_eli.ko: Exec format error After patch: kldload: can't load geom_eli.ko: Exec format error kldload: Dependendent kernel module cannot be loaded from kern.module_path? Comments? The reason I vote know is that ENOEXEC can mean several things. I thought you had a patch to catch the actual kernel error message and pass it back to userland. That would be a useful feature, but this message doesn't really help and can point people in the wrong direction if their error is due to a different problem. If you want to help the user, then I think a more useful approach would be to tell the user to check dmesg for error messages when kldload(2) fails with ENOEXEC. -- John Baldwin ___ 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: Broadcom BCM4310 USB Controller (Wifi)
On 10/26/10, Alberto Villa avi...@freebsd.org wrote: On Mon, Oct 25, 2010 at 1:07 AM, Matthias Apitz g...@unixarea.de wrote: I have a new laptop Acer Aspire One D250 and pulled out HEAD from SVN today morning. As far as I can see in sys/dev/bwi and sys/dev/bwn the above chip is still not supported. I am wrong? i have the same problem with a BCM43225. there is a linux driver: is anyone going to port it in the near future? would a donation help the process? Any other idea how to get Wifi working on this mini laptop? i've tried ndis without success... Sharing you experience would help (if you are not on amd64). ___ 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
intr_event_destroy(9)
It looks like a bug in intr_event_destroy(9): I'm trying to unload a
new driver being developed internally for NVRAM, and I get this
WITNESS warning and hang:
# kldunload rnv
Sleeping on ithdty with the following non-sleepable locks held:
exclusive sleep mutex intr event list (intr event list) r = 0
(0x806f9560) locked @
/data/sb/BR_BONNEVILLE_HW/src/sys/kern/kern_intr.c:404
KDB: stack backtrace:
[801a544d] db_trace_self_wrapper+0x3d
[802e7b26] witness_warn+0x2f6
[802a1a43] _sleep+0xc3
[8026dad5] intr_event_destroy+0xe5
[ff87b05ba805] rnv_pci_detach+0xc5
[802c9414] device_detach+0xb4
[802c974f] devclass_delete_driver+0xdf
[802c991d] driver_module_handler+0x11d
[802843a2] module_unload+0x42
[80279f4b] linker_file_unload+0x19b
[8027aa1b] kern_kldunload+0x10b
[802a2609] isi_syscall+0x99
[804dee3e] ia32_syscall+0x1ce
[804a7e50] Xint0x80_syscall+0x60
--- syscall (444, FreeBSD ELF32, kldunloadf), rip = 0x280c1aff, rsp =
0xd44c, rbp = 0xdc98 ---
Looking at intr_event_destroy, I see this snippet from r157728:
#ifndef notyet
if (ie-ie_thread != NULL) {
ithread_destroy(ie-ie_thread);
ie-ie_thread = NULL;
}
#endif
There is an msleep(9) in ithread_destroy(9). And everywhere else that
uses notyet has #ifdef, not #ifndef. So... is this a typo?
Thanks,
matthew
___
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: intr_event_destroy(9)
On Tuesday, October 26, 2010 11:55:10 am Matthew Fleming wrote:
It looks like a bug in intr_event_destroy(9): I'm trying to unload a
new driver being developed internally for NVRAM, and I get this
WITNESS warning and hang:
# kldunload rnv
Sleeping on ithdty with the following non-sleepable locks held:
exclusive sleep mutex intr event list (intr event list) r = 0
(0x806f9560) locked @
/data/sb/BR_BONNEVILLE_HW/src/sys/kern/kern_intr.c:404
KDB: stack backtrace:
[801a544d] db_trace_self_wrapper+0x3d
[802e7b26] witness_warn+0x2f6
[802a1a43] _sleep+0xc3
[8026dad5] intr_event_destroy+0xe5
[ff87b05ba805] rnv_pci_detach+0xc5
[802c9414] device_detach+0xb4
[802c974f] devclass_delete_driver+0xdf
[802c991d] driver_module_handler+0x11d
[802843a2] module_unload+0x42
[80279f4b] linker_file_unload+0x19b
[8027aa1b] kern_kldunload+0x10b
[802a2609] isi_syscall+0x99
[804dee3e] ia32_syscall+0x1ce
[804a7e50] Xint0x80_syscall+0x60
--- syscall (444, FreeBSD ELF32, kldunloadf), rip = 0x280c1aff, rsp =
0xd44c, rbp = 0xdc98 ---
Looking at intr_event_destroy, I see this snippet from r157728:
#ifndef notyet
if (ie-ie_thread != NULL) {
ithread_destroy(ie-ie_thread);
ie-ie_thread = NULL;
}
#endif
There is an msleep(9) in ithread_destroy(9). And everywhere else that
uses notyet has #ifdef, not #ifndef. So... is this a typo?
No, it's actually on purpose I think as the other bits under notyet destroy
the thread when the last handler for it goes away.
However, ithread_destroy() does not block in any of 7.x or later:
static void
ithread_destroy(struct intr_thread *ithread)
{
struct thread *td;
CTR2(KTR_INTR, %s: killing %s, __func__, ithread-it_event-ie_name);
td = ithread-it_thread;
thread_lock(td);
ithread-it_flags |= IT_DEAD;
if (TD_AWAITING_INTR(td)) {
TD_CLR_IWAIT(td);
sched_add(td, SRQ_INTR);
}
thread_unlock(td);
}
Maybe you have a local change? If so, you can probably unlock the global
event_list lock before calling ithread_destroy() (but after the
TAILQ_REMOVE()) in intr_event_destroy().
--
John Baldwin
___
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: intr_event_destroy(9)
On Tue, Oct 26, 2010 at 9:46 AM, John Baldwin j...@freebsd.org wrote:
On Tuesday, October 26, 2010 11:55:10 am Matthew Fleming wrote:
It looks like a bug in intr_event_destroy(9): I'm trying to unload a
new driver being developed internally for NVRAM, and I get this
WITNESS warning and hang:
# kldunload rnv
Sleeping on ithdty with the following non-sleepable locks held:
exclusive sleep mutex intr event list (intr event list) r = 0
(0x806f9560) locked @
/data/sb/BR_BONNEVILLE_HW/src/sys/kern/kern_intr.c:404
KDB: stack backtrace:
[801a544d] db_trace_self_wrapper+0x3d
[802e7b26] witness_warn+0x2f6
[802a1a43] _sleep+0xc3
[8026dad5] intr_event_destroy+0xe5
[ff87b05ba805] rnv_pci_detach+0xc5
[802c9414] device_detach+0xb4
[802c974f] devclass_delete_driver+0xdf
[802c991d] driver_module_handler+0x11d
[802843a2] module_unload+0x42
[80279f4b] linker_file_unload+0x19b
[8027aa1b] kern_kldunload+0x10b
[802a2609] isi_syscall+0x99
[804dee3e] ia32_syscall+0x1ce
[804a7e50] Xint0x80_syscall+0x60
--- syscall (444, FreeBSD ELF32, kldunloadf), rip = 0x280c1aff, rsp =
0xd44c, rbp = 0xdc98 ---
Looking at intr_event_destroy, I see this snippet from r157728:
#ifndef notyet
if (ie-ie_thread != NULL) {
ithread_destroy(ie-ie_thread);
ie-ie_thread = NULL;
}
#endif
There is an msleep(9) in ithread_destroy(9). And everywhere else that
uses notyet has #ifdef, not #ifndef. So... is this a typo?
No, it's actually on purpose I think as the other bits under notyet destroy
the thread when the last handler for it goes away.
However, ithread_destroy() does not block in any of 7.x or later:
static void
ithread_destroy(struct intr_thread *ithread)
{
struct thread *td;
CTR2(KTR_INTR, %s: killing %s, __func__, ithread-it_event-ie_name);
td = ithread-it_thread;
thread_lock(td);
ithread-it_flags |= IT_DEAD;
if (TD_AWAITING_INTR(td)) {
TD_CLR_IWAIT(td);
sched_add(td, SRQ_INTR);
}
thread_unlock(td);
}
Maybe you have a local change? If so, you can probably unlock the global
event_list lock before calling ithread_destroy() (but after the
TAILQ_REMOVE()) in intr_event_destroy().
Gah, yes, it looks like a local change we can probably do without.
And as it turns out the driver can pass NULL to siw_add() and skip the
intr_event_destroy() anyways.
Thanks for the help!
Sorry for the noise.
matthew
___
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
Event based scheduling and USB.
I updated my FreeBSD tree on laptop, to the current as of 18 Oct.2010, it works fine with CPU C3 state enabled, I think this is your achievement of event time scheduler, thanks! But when USB driver is enabled, the load average is considerablly high (0.6 to 1.0) if sysctl oid kern.eventtimer.periodic is set to 0. Then kern.eventtimer.periodic is set to 1, the load average goes to 0 quickly as before, but almost never transit to C3. Is this behavior expected, or something wrong? I noticed one of usb host controller device shares HPET irq. When I implement interrupt filter in uhci driver, the load average goes to 0 as before. % vmstat -i interrupt total rate irq1: atkbd0 398 2 irq9: acpi0 408 2 irq12: psm03 0 irq19: ehci1 37 0 irq20: hpet0 uhci0 35970230 irq22: ehci0 2 0 irq256: em04 0 irq257: ahci0 1692 10 Total 38514246 === BTW, when USB port is enabled C3 transition rate gets lower. I think it is likely to occur. But how can I supress power consumption? It's time to implement powertop for freebsd, isn't it? ___ 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: Event based scheduling and USB.
Takanori Watanabe wrote: I updated my FreeBSD tree on laptop, to the current as of 18 Oct.2010, it works fine with CPU C3 state enabled, I think this is your achievement of event time scheduler, thanks! But when USB driver is enabled, the load average is considerablly high (0.6 to 1.0) if sysctl oid kern.eventtimer.periodic is set to 0. Then kern.eventtimer.periodic is set to 1, the load average goes to 0 quickly as before, but almost never transit to C3. Is this behavior expected, or something wrong? I noticed one of usb host controller device shares HPET irq. When I implement interrupt filter in uhci driver, the load average goes to 0 as before. % vmstat -i interrupt total rate irq1: atkbd0 398 2 irq9: acpi0 408 2 irq12: psm03 0 irq19: ehci1 37 0 irq20: hpet0 uhci0 35970230 irq22: ehci0 2 0 irq256: em04 0 irq257: ahci0 1692 10 Total 38514246 === I haven't noticed that issue and it is surely not expected for me. I will try to reproduce it. Most likely you should be able to avoid interrupt sharing using some additional HPET options, described at hpet(4). BTW, when USB port is enabled C3 transition rate gets lower. I think it is likely to occur. But how can I supress power consumption? I can't say about USB, but you may try this patch to optimize some other subsystems: http://people.freebsd.org/~mav/tm6292_idle.patch It's time to implement powertop for freebsd, isn't it? Surely it is. I was even thinking about possibility to port one from OpenSolaris, but other work distracted me. You may take it, it you wish. -- Alexander Motin ___ 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: Event based scheduling and USB.
On 10/26/2010 12:57 PM, Alexander Motin wrote: Takanori Watanabe wrote: I updated my FreeBSD tree on laptop, to the current as of 18 Oct.2010, it works fine with CPU C3 state enabled, I think this is your achievement of event time scheduler, thanks! Ah, so mav@ implemented a tickless-scheduler? That is nice. But when USB driver is enabled, the load average is considerablly high (0.6 to 1.0) if sysctl oid kern.eventtimer.periodic is set to 0. Then kern.eventtimer.periodic is set to 1, the load average goes to 0 quickly as before, but almost never transit to C3. Is this behavior expected, or something wrong? The USB controller often keeps the bus mastering bit set. This keeps the system out of C3. The way to fix this is to implement global suspend. Put a device in suspend mode and then turn off power to the USB port it is on. Then the USB controller will stop polling the bus. I noticed one of usb host controller device shares HPET irq. When I implement interrupt filter in uhci driver, the load average goes to 0 as before. % vmstat -i interrupt total rate irq1: atkbd0 398 2 irq9: acpi0 408 2 irq12: psm03 0 irq19: ehci1 37 0 irq20: hpet0 uhci0 35970230 irq22: ehci0 2 0 irq256: em04 0 irq257: ahci0 1692 10 Total 38514246 === I haven't noticed that issue and it is surely not expected for me. I will try to reproduce it. Most likely you should be able to avoid interrupt sharing using some additional HPET options, described at hpet(4). This seems silly. The whole point of APIC is to avoid clustering on a single interrupt but the BIOS put the timer on the USB controller irq? It's time to implement powertop for freebsd, isn't it? Surely it is. I was even thinking about possibility to port one from OpenSolaris, but other work distracted me. You may take it, it you wish. It seems worth doing the internals new, but maybe outputting information in a compatible format for reporting tools. -- Nate ___ 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
