Re: btxld not found
>
>>> Could anyone explain to me what I am doing wrong? make installworld fails
>>> each time with the following error
>>>
>>> ===> stand/i386/libi386 (install)
>>> ===> stand/i386/loader_4th (install)
>>> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
>>> btxld -v -f aout -e 0x20 -o loader_4th -l
>>> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b
>>> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
>>> make[6]: exec(btxld) failed (No such file or directory)
>>> *** Error code 1
>>>
>>> This is with source of last week. I had this problem before (from old
>>> sources) and fixed it by specifying the full path to btxld in the
>>> stand/i386/*/Makefile.
>>
>> Yes, this is most likely your clock(s) being off. At installworld time,
>> it should *not* start rebuilding your loader.
>>
>> Usually this happens if you build on one machine, and install on
>> another, while the install machine's time is behind the build machine's
>> time. But it can also happens on one machine, for instance if you
>> start in single user mode, and the clock is not yet synchronized.
>>
>> -Dimitry
>>
> Dimitry,
>
> My VirtualBox VMs do have a tendency to lag when I am not using them for a
> while. I've adjusted time and started ntpd. In the past that would not fix
> the time lag permanently.
>
> I'll do a fresh buildworld and see whether that completes.
>
> Nick
Nope, make buildworld && make installworld results in, so I guess the job
ordering suggestion is a better one (VM with 2 processors on a variably loaded
laptop, no -j option, time accurate):
install -o root -g wheel -m 444 mbr /boot/mbr
===> stand/i386/pmbr (install)
install -o root -g wheel -m 444 pmbr /boot/pmbr
===> stand/i386/boot0 (install)
install -o root -g wheel -m 444 boot0 /boot/boot0
===> stand/i386/boot0sio (install)
install -o root -g wheel -m 444 boot0 /boot/boot0sio
===> stand/i386/btx (install)
===> stand/i386/btx/btx (install)
===> stand/i386/btx/btxldr (install)
===> stand/i386/btx/lib (install)
===> stand/i386/boot2 (install)
objcopy -S -O binary boot1.out boot1
objcopy -S -O binary boot2.out boot2.bin
btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx
-l boot2.ldr -o boot2.ld -P 1 boot2.bin
make[6]: exec(btxld) failed (No such file or directory)
*** Error code 1
...
{e}nick@fimkjecurrent:/usr/src % sudo find / -name btxld -type f -ls
1908308 48 -r-xr-xr-x1 root wheel
22988 Jan 27 23:37 /usr/sbin/btxld
3441268 52 -rwxr-xr-x1 root wheel
25816 Jan 29 16:09
/usr/obj/usr/src/i386.i386/usr.sbin/btxld/btxld
{e}nick@fimkjecurrent:/usr/src % date
Wed Jan 29 16:30:21 CET 2020
{e}nick@fimkjecurrent:/usr/src % make -dA
...
Global:MFLAGS = -d A
job_pipe -1 -1, maxjobs 1, tokens 1, compat 1
...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: btxld not found
>> Could anyone explain to me what I am doing wrong? make installworld fails >> each time with the following error >> >> ===> stand/i386/libi386 (install) >> ===> stand/i386/loader_4th (install) >> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym >> btxld -v -f aout -e 0x20 -o loader_4th -l >> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b >> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin >> make[6]: exec(btxld) failed (No such file or directory) >> *** Error code 1 >> >> This is with source of last week. I had this problem before (from old >> sources) and fixed it by specifying the full path to btxld in the >> stand/i386/*/Makefile. > > Yes, this is most likely your clock(s) being off. At installworld time, > it should *not* start rebuilding your loader. > > Usually this happens if you build on one machine, and install on > another, while the install machine's time is behind the build machine's > time. But it can also happens on one machine, for instance if you > start in single user mode, and the clock is not yet synchronized. > > -Dimitry > Dimitry, My VirtualBox VMs do have a tendency to lag when I am not using them for a while. I've adjusted time and started ntpd. In the past that would not fix the time lag permanently. I'll do a fresh buildworld and see whether that completes. Nick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: btxld not found
> On Tue, Jan 28, 2020, 4:57 AM Nick Hibma <mailto:n...@van-laarhoven.org>> wrote:
> > On 28/01 /2020, at 12:39, Toomas Soome > <mailto:tso...@me.com>> wrote:
> >
> >> On 28. Jan 2020, at 13:36, Nick Hibma >> <mailto:n...@van-laarhoven.org>> wrote:
> >>
> >> Folks,
> >>
> >> Could anyone explain to me what I am doing wrong? make installworld fails
> >> each time with the following error
> >>
> >> ===> stand/i386/libi386 (install)
> >> ===> stand/i386/loader_4th (install)
> >> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
> >> btxld -v -f aout -e 0x20 -o loader_4th -l
> >> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b
> >> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
> >> make[6]: exec(btxld) failed (No such file or directory)
> >> *** Error code 1
> >>
> >> This is with source of last week. I had this problem before (from old
> >> sources) and fixed it by specifying the full path to btxld in the
> >> stand/i386/*/Makefile.
> >>
> >> Any pointers?
> >>
> >
> > it should be /usr/sbin/btxld; are you missing /usr/sbin from the path?
>
> Well, it's an 'installworld' so I would expect it to be providing that
> program itself, but no, /usr/sbin/ is in the path of the current shell.
>
> Also, in some of the makefiles the target calling btxldr is depending on the
> build of that executable:
>
> Index: stand/i386/pxeldr/Makefile
> ===
> --- stand/i386/pxeldr/Makefile (revision 357042)
> +++ stand/i386/pxeldr/Makefile (working copy)
> @@ -39,7 +39,7 @@
> CLEANFILES+= ${LOADER}
>
> ${LOADER}: ${LOADERBIN} ${BTXLDR} ${BTXKERN}
> - btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l ${BTXLDR} \
> + /usr/sbin/btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l
> ${BTXLDR} \
> -b ${BTXKERN} ${LOADERBIN}
>
> This is definitely wrong. We have either a path that is wrong, or we aren't
> reinstalling btxld in the right place.
>
> Warner
This is not a fix, this is to get me through the installworld. As I've not seen
any mention of this the past 6 months it must be something on my system that
makes things go bad, but I have no idea what.
They are being built, and installed:
{e}nick@fimkjecurrent:/usr/src/stand/i386/btx % find / -name btxld -ls
1908308 48 -r-xr-xr-x1 root wheel
22988 Jan 27 23:37 /usr/sbin/btxld
13190104 drwxr-xr-x2 nick nick
512 Sep 15 2017 /usr/src/usr.sbin/btxld
33695644 drwxrwxr-x2 root wheel
512 Jan 27 22:33
/usr/obj/usr/src/i386.i386/usr.sbin/btxld
3371323 52 -rwxr-xr-x1 root wheel
25816 Jan 27 22:33
/usr/obj/usr/src/i386.i386/usr.sbin/btxld/btxld
I guess the difference in file size is due to it being stripped during install?
Nick
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: btxld not found
> On 28/01 /2020, at 12:39, Toomas Soome wrote:
>
>> On 28. Jan 2020, at 13:36, Nick Hibma wrote:
>>
>> Folks,
>>
>> Could anyone explain to me what I am doing wrong? make installworld fails
>> each time with the following error
>>
>> ===> stand/i386/libi386 (install)
>> ===> stand/i386/loader_4th (install)
>> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
>> btxld -v -f aout -e 0x20 -o loader_4th -l
>> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b
>> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
>> make[6]: exec(btxld) failed (No such file or directory)
>> *** Error code 1
>>
>> This is with source of last week. I had this problem before (from old
>> sources) and fixed it by specifying the full path to btxld in the
>> stand/i386/*/Makefile.
>>
>> Any pointers?
>>
>
> it should be /usr/sbin/btxld; are you missing /usr/sbin from the path?
Well, it's an 'installworld' so I would expect it to be providing that program
itself, but no, /usr/sbin/ is in the path of the current shell.
Also, in some of the makefiles the target calling btxldr is depending on the
build of that executable:
Index: stand/i386/pxeldr/Makefile
===
--- stand/i386/pxeldr/Makefile (revision 357042)
+++ stand/i386/pxeldr/Makefile (working copy)
@@ -39,7 +39,7 @@
CLEANFILES+= ${LOADER}
${LOADER}: ${LOADERBIN} ${BTXLDR} ${BTXKERN}
- btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l ${BTXLDR} \
+ /usr/sbin/btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l
${BTXLDR} \
-b ${BTXKERN} ${LOADERBIN}
Nick
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
btxld not found
Folks, Could anyone explain to me what I am doing wrong? make installworld fails each time with the following error ===> stand/i386/libi386 (install) ===> stand/i386/loader_4th (install) strip -R .comment -R .note -o loader_4th.bin loader_4th.sym btxld -v -f aout -e 0x20 -o loader_4th -l /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr -b /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin make[6]: exec(btxld) failed (No such file or directory) *** Error code 1 This is with source of last week. I had this problem before (from old sources) and fixed it by specifying the full path to btxld in the stand/i386/*/Makefile. Any pointers? Nick Hibma n...@van-laarhoven.org -- Open Source: We stand on the shoulders of giants. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694
That (with the return added, thanks Cy) worked like a charm.
Thanks for the fast response.
Nick Hibma
n...@van-laarhoven.org
-- Open Source: We stand on the shoulders of giants.
> On 21 Jan 2020, at 18:38, Alexander V. Chernikov wrote:
>
> 21.01.2020, 17:25, "Nick Hibma" :
>> When using a trivial program to read from the divert socket and post back
>> the machine panics instantly when a packet is sent to userland and back
>> again (incoming packet for the interface, so ifname is set). This is current
>> from today with no changes
>>
>> Any pointers as to how to fix this?
> Could you please try to apply an attached patch and try again?
>>
>> Thanks in advance for any help.
>>
>> Nick Hibma
>> n...@van-laarhoven.org
>>
>> -- Open Source: We stand on the shoulders of giants.
>>
>> Unread portion of the kernel message buffer:
>> panic: Assertion in_epoch(net_epoch_preempt) failed at
>> /usr/src/sys/netinet/in.c:968
>> cpuid = 0
>> time = 1579626632
>> KDB: stack backtrace:
>> db_trace_self_wrapper(3836393a,1a9000a,0,1fdc088c,bd5320,...) at
>> db_trace_self_wrapper+0x2a/frame 0x1fdc0860
>> kdb_backtrace(2,1e03ebc,1fdc08e8,14683a4,20b72500,...) at
>> kdb_backtrace+0x2e/frame 0x1fdc08c0
>> vpanic(1461278,1fdc0904,1fdc0904,1fdc0918,11355ac,...) at vpanic+0x11f/frame
>> 0x1fdc08e4
>> panic(1461278,1512573,154b440,3c8,20b72500,...) at panic+0x14/frame
>> 0x1fdc08f8
>> in_broadcast(f02000a,94df400,20b72594,1dc0ae8,2001be24,...) at
>> in_broadcast+0x8c/frame 0x1fdc0918
>> div_send(2001bcc0,0,20b72500,9082e10,0,177f1a80) at div_send+0x1bd/frame
>> 0x1fdc0958
>> sosend_generic(2001bcc0,9082e10,1fdc0a18,0,0,0,177f1a80) at
>> sosend_generic+0x3c5/frame 0x1fdc09b4
>> sosend(2001bcc0,9082e10,1fdc0a18,0,0,...) at sosend+0x50/frame 0x1fdc09e4
>> kern_sendit(177f1a80,3,1fdc0aa0,0,0,0) at kern_sendit+0x1b4/frame 0x1fdc0a50
>> sendit(1fdc0aa0,0) at sendit+0x196/frame 0x1fdc0a88
>> sys_sendto(177f1a80,177f1d0c) at sys_sendto+0x50/frame 0x1fdc0ac8
>> syscall(1fdc0ba8,3b,3b,3b,54,...) at syscall+0x2db/frame 0x1fdc0b9c
>> Xint0x80_syscall() at 0xffc033c9/frame 0x1fdc0b9c
>> --- syscall (133, FreeBSD ELF32, sys_sendto), eip = 0xffc01230, esp =
>> 0xffc07fe8, ebp = 0xffbfeb68 ---
>> KDB: enter: panic
>>
>> 0x00fd1129 in doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:392
>> 392 savectx();
>> (kgdb) quit
>> {e}nick@fimkjecurrent:/home/nick % svn info /usr/src
>> Path: /usr/src
>> Working Copy Root Path: /usr/src
>> URL: svn+ssh://repo.freebsd.org/base/head
>> Relative URL: ^/head
>> Repository Root: svn+ssh://repo.freebsd.org/base
>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>> Revision: 356907
>> Node Kind: directory
>> Schedule: normal
>> Last Changed Author: jhibbits
>> Last Changed Rev: 356904
>> Last Changed Date: 2020-01-20 05:01:35 +0100 (Mon, 20 Jan 2020)
>>
>>> On 9 Oct 2019, at 14:04, David Wolfskill wrote:
>>>
>>> On Tue, Oct 08, 2019 at 05:15:19AM -0700, David Wolfskill wrote:
>>>> This was on my laptop (build machine, which was updated in parallel,
>>>> but uses a different NIC, had no issues) after a src update from
>>>> r353176 to r353298; laptop's NIC is wlan(4) (which is iwn(4), in
>>>> this case).
>>>
>>> After restoring the /boot/*.old set, I was able to reboot & update from
>>> r353298 to r353336. The subsequent reboot seemed OK ... until the
>>> keyboard & mouse were enabled (under X11; I use xdm on the laptop).
>>>
>>> Then I got a slightly different panic:
>>>
>>> panic: Assertion in_epoch(net_epoch_preempt) failed at
>>> /usr/src/sys/net/if.c:356
>>>
>>> Backtrace:
>>>
>>> panic: Assertion in_epoch(net_epoch_preempt) failed at
>>> /usr/src/sys/net/if.c:356
>>> cpuid = 0
>>> time = 1570621553
>>> KDB: stack backtrace:
>>> db_trace_self_wrapper() at 0x8049ebab =
>>> db_trace_self_wrapper+0x2b/frame 0xfe1072956580
>>> vpanic() at 0x80b978fd = vpanic+0x19d/frame 0xfe10729565d0
>>> panic() at 0x80b97693 = panic+0x43/frame 0xfe1072956630
>>> if_ref() at 0x80ca1b10 = if_ref/frame 0xfe1072956650
>>> sysctl_ifdata() at 0x80cb247d = sysctl_ifdata+0x4d/frame
>>> 0xfe1072956760
>>> sysctl_root_handler_locked() at 0x80ba714b =
>>> sysctl_root_handler_locked+0x7b/frame 0xfe107
Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694
When using a trivial program to read from the divert socket and post back the
machine panics instantly when a packet is sent to userland and back again
(incoming packet for the interface, so ifname is set). This is current from
today with no changes
Any pointers as to how to fix this?
Thanks in advance for any help.
Nick Hibma
n...@van-laarhoven.org
-- Open Source: We stand on the shoulders of giants.
Unread portion of the kernel message buffer:
panic: Assertion in_epoch(net_epoch_preempt) failed at
/usr/src/sys/netinet/in.c:968
cpuid = 0
time = 1579626632
KDB: stack backtrace:
db_trace_self_wrapper(3836393a,1a9000a,0,1fdc088c,bd5320,...) at
db_trace_self_wrapper+0x2a/frame 0x1fdc0860
kdb_backtrace(2,1e03ebc,1fdc08e8,14683a4,20b72500,...) at
kdb_backtrace+0x2e/frame 0x1fdc08c0
vpanic(1461278,1fdc0904,1fdc0904,1fdc0918,11355ac,...) at vpanic+0x11f/frame
0x1fdc08e4
panic(1461278,1512573,154b440,3c8,20b72500,...) at panic+0x14/frame 0x1fdc08f8
in_broadcast(f02000a,94df400,20b72594,1dc0ae8,2001be24,...) at
in_broadcast+0x8c/frame 0x1fdc0918
div_send(2001bcc0,0,20b72500,9082e10,0,177f1a80) at div_send+0x1bd/frame
0x1fdc0958
sosend_generic(2001bcc0,9082e10,1fdc0a18,0,0,0,177f1a80) at
sosend_generic+0x3c5/frame 0x1fdc09b4
sosend(2001bcc0,9082e10,1fdc0a18,0,0,...) at sosend+0x50/frame 0x1fdc09e4
kern_sendit(177f1a80,3,1fdc0aa0,0,0,0) at kern_sendit+0x1b4/frame 0x1fdc0a50
sendit(1fdc0aa0,0) at sendit+0x196/frame 0x1fdc0a88
sys_sendto(177f1a80,177f1d0c) at sys_sendto+0x50/frame 0x1fdc0ac8
syscall(1fdc0ba8,3b,3b,3b,54,...) at syscall+0x2db/frame 0x1fdc0b9c
Xint0x80_syscall() at 0xffc033c9/frame 0x1fdc0b9c
--- syscall (133, FreeBSD ELF32, sys_sendto), eip = 0xffc01230, esp =
0xffc07fe8, ebp = 0xffbfeb68 ---
KDB: enter: panic
0x00fd1129 in doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:392
392 savectx();
(kgdb) quit
{e}nick@fimkjecurrent:/home/nick % svn info /usr/src
Path: /usr/src
Working Copy Root Path: /usr/src
URL: svn+ssh://repo.freebsd.org/base/head
Relative URL: ^/head
Repository Root: svn+ssh://repo.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 356907
Node Kind: directory
Schedule: normal
Last Changed Author: jhibbits
Last Changed Rev: 356904
Last Changed Date: 2020-01-20 05:01:35 +0100 (Mon, 20 Jan 2020)
> On 9 Oct 2019, at 14:04, David Wolfskill wrote:
>
> On Tue, Oct 08, 2019 at 05:15:19AM -0700, David Wolfskill wrote:
>> This was on my laptop (build machine, which was updated in parallel,
>> but uses a different NIC, had no issues) after a src update from
>> r353176 to r353298; laptop's NIC is wlan(4) (which is iwn(4), in
>> this case).
>
> After restoring the /boot/*.old set, I was able to reboot & update from
> r353298 to r353336. The subsequent reboot seemed OK ... until the
> keyboard & mouse were enabled (under X11; I use xdm on the laptop).
>
> Then I got a slightly different panic:
>
> panic: Assertion in_epoch(net_epoch_preempt) failed at
> /usr/src/sys/net/if.c:356
>
> Backtrace:
>
> panic: Assertion in_epoch(net_epoch_preempt) failed at
> /usr/src/sys/net/if.c:356
> cpuid = 0
> time = 1570621553
> KDB: stack backtrace:
> db_trace_self_wrapper() at 0x8049ebab =
> db_trace_self_wrapper+0x2b/frame 0xfe1072956580
> vpanic() at 0x80b978fd = vpanic+0x19d/frame 0xfe10729565d0
> panic() at 0x80b97693 = panic+0x43/frame 0xfe1072956630
> if_ref() at 0x80ca1b10 = if_ref/frame 0xfe1072956650
> sysctl_ifdata() at 0x80cb247d = sysctl_ifdata+0x4d/frame
> 0xfe1072956760
> sysctl_root_handler_locked() at 0x80ba714b =
> sysctl_root_handler_locked+0x7b/frame 0xfe10729567a0
> sysctl_root() at 0x80ba64dc = sysctl_root+0x20c/frame
> 0xfe1072956820
> userland_sysctl() at 0x80ba6bab = userland_sysctl+0x17b/frame
> 0xfe10729568d0
> sys___sysctl() at 0x80ba69ef = sys___sysctl+0x5f/frame
> 0xfe1072956980
> amd64_syscall() at 0x810480f4 = amd64_syscall+0x2d4/frame
> 0xfe1072956ab0
> fast_syscall_common() at 0x8101eaa0 = fast_syscall_common+0x101/frame
> 0xfe1072956ab0
> --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x8014d4d2a, rsp =
> 0x7fffeaa8, rbp = 0x7fffeae0 ---
> KDB: enter: panic
>
>> The ddb "dump" command recorded a dump, which I managed to capture; the
>> information may be found at
>> http://www.catwhisker.org/~david/FreeBSD/head/r353298/
>
> This one is at http://www.catwhisker.org/~david/FreeBSD/head/r353336
>
> As before, the (headless) build machine had no issues that I could see.
>
> Peace,
> david
> --
> David H. Wolfskillda...@catwhisker.org
> I am amazed that anyone would condone what Trunp has publicly admit
change to divert socket's sockaddr argument to include FIB
Folks,
I've been bitten several times now by the fact that FIB values do not survive
going through a divert socket. This is resolved by giving a divert socket its
own type that stores this information (and potentially more in the future).
I've attached a patch that would resolve 2 things:
a) interface names that are longer than 7 characters (someone suggested this
somewhere for interfaces with auto generated names).
b) FIB's getting lost after going through a divert socket (for example with
natd).
I am now using the following structure:
struct sockaddr_div {
uint8_t sdiv_len;
sa_family_t sdiv_family;
in_port_t sdiv_port;
struct in_addr sdiv_addr;
charsdiv_ifnam[IF_NAMESIZE]; // name of
incoming interface or "\0"
uint16_tsdiv_fib; // routing fib
};
This should be a no-op for most cases, like natd, that reuse the sockaddr_in as
is. I cannot find any relevant reference to sin_zero in base, but for cases
where the interface name is read it should be a no-op as well, unless . This
code is in use here, and seems to work fine, but additional testing is
obviously welcome.
Patch attached.
As this is an API change, I would appreciate some feedback on whether this is a
good idea, whether more information should be stored in the struct, etc.
Second, is this something that should be MFCed?
Regards,
Nick Hibma
n...@van-laarhoven.org
-- Open Source: We stand on the shoulders of giants.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: How do GEOM_PART_* options configure geom_part_* modules??
>> I created a new kernel config file from scratch, wondered what the >> GEOM_PART_MBR option and friends were doing, search for them, didn't find >> them in the tree, and deleted them from my config. But... de resulting disk >> image didn't boot, because of the fact that it didn't recognise the MBR >> partitions (it only had a single diskid entry on the mount-root prompt). >> >> Can anyone explain to me how these kernel options work, as in: they are >> defined in kernel configs and as a consequence in opt_geom.h, but how are >> they actually used to select which geom_part_* modules/kernel parts to >> build? I thought these options were translated to stuff that cpp would use, >> but there are not uses of for example GEOM_PART_MBR anywhere for example! >> > > The module always build them because they are listed in the module's > Makefile. > > The kernel only sometimes does. Here's the key lines from conf/files: > files:geom/geom_bsd_enc.c optional geom_bsd | geom_part_bsd > files:geom/part/g_part_apm.c optional geom_part_apm > files:geom/part/g_part_bsd.c optional geom_part_bsd > files:geom/part/g_part_bsd64.c optional geom_part_bsd64 > files:geom/part/g_part_ebr.c optional geom_part_ebr > files:geom/part/g_part_gpt.c optional geom_part_gpt > files:geom/part/g_part_ldm.c optional geom_part_ldm > files:geom/part/g_part_mbr.c optional geom_part_mbr > files:geom/part/g_part_vtoc8.c optional geom_part_vtoc8 > > which turn on/off which files get included. config "helpfully" converts the > upper case options to lower case for this. > > Warner *slaps forehead* Goose chase! I actually knew that... and, at the time, thought it was weird behaviour. ''grep" would not have failed me if those options would be uppercase there ... Thanks, Warner. Nick signature.asc Description: Message signed with OpenPGP
How do GEOM_PART_* options configure geom_part_* modules??
I created a new kernel config file from scratch, wondered what the GEOM_PART_MBR option and friends were doing, search for them, didn't find them in the tree, and deleted them from my config. But... de resulting disk image didn't boot, because of the fact that it didn't recognise the MBR partitions (it only had a single diskid entry on the mount-root prompt). Can anyone explain to me how these kernel options work, as in: they are defined in kernel configs and as a consequence in opt_geom.h, but how are they actually used to select which geom_part_* modules/kernel parts to build? I thought these options were translated to stuff that cpp would use, but there are not uses of for example GEOM_PART_MBR anywhere for example! The only thing I was able to come up with, but could not figure out, was FEATURE() doing some magic. Thanks in advance for any pointers! Nick Hibma n...@van-laarhoven.org <mailto:n...@van-laarhoven.org> -- Open Source: We stand on the shoulders of giants. % grep -r GEOM_PART_ /usr/src/sys/ | grep -Ev '/conf/.*options' /usr/src/sys/geom/part/g_part_mbr.c:"GEOM_PART_MBR Master Boot Record"); /usr/src/sys/geom/part/g_part_ldm.c:"GEOM_PART_LDM Logical Disk Manager"); /usr/src/sys/geom/part/g_part_ldm.c: * XXX: We use some knowledge about GEOM_PART_GPT internal /usr/src/sys/geom/part/g_part_ebr.c:#if defined(GEOM_PART_EBR_COMPAT) /usr/src/sys/geom/part/g_part_ebr.c:#ifndef GEOM_PART_EBR_COMPAT /usr/src/sys/geom/part/g_part_ebr.c:#if defined(GEOM_PART_EBR_COMPAT) /usr/src/sys/geom/part/g_part_ebr.c:#if defined(GEOM_PART_EBR_COMPAT) /usr/src/sys/geom/part/g_part_ebr.c:#if defined(GEOM_PART_EBR_COMPAT) /usr/src/sys/geom/part/g_part_ebr.c:#if defined(GEOM_PART_EBR_COMPAT) /usr/src/sys/geom/part/g_part_ebr.c:#ifndef GEOM_PART_EBR_COMPAT /usr/src/sys/geom/part/g_part_ebr.c:#ifndef GEOM_PART_EBR_COMPAT /usr/src/sys/geom/part/g_part_ebr.c:#ifndef GEOM_PART_EBR_COMPAT /usr/src/sys/geom/part/g_part_ebr.c:#ifndef GEOM_PART_EBR_COMPAT /usr/src/sys/geom/part/g_part.h:#ifndef _GEOM_PART_H_ /usr/src/sys/geom/part/g_part.h:#define _GEOM_PART_H_ /usr/src/sys/geom/part/g_part.h:#endif /* !_GEOM_PART_H_ */ signature.asc Description: Message signed with OpenPGP
Re: Compiler optimisation bug
>> Should this be reported to the clang folks? Or is this to be expected when >> abusing integer overflows this way? > > You will get an answer that this is expected. Add -fwrapv compiler flag > to make signed arithmetic behave in a way different from the mine-field, > or remove the code. For kernel, we use -fwrapv. Thanks, that was what I expected. I searched for -fwrapv and found similar comments. The code has been rewritten to not depend on overflow for its checks, so it works properly with any sized time_t (assuming that it is an integer though :). I'll commit it after feedback. Nick signature.asc Description: Message signed with OpenPGP
Compiler optimisation bug
There is a bug in sbin/dhclient.c for large expiry values on 32 bit platforms
where time_t is a uint32_t (bug #218980,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218980). It is caused by a
compiler optimisation that removes an if-statement. The code below shows the
following output, clearly showing that the optimised case provides a different
answer:
% cc -O2 main.c -o main.a && ./main.a
no opt: 0x7fff
with opt: 0xfffe
rephrased: 0x7fff
The code is as follows:
% cat main.c
#include
#include
#define TIME_MAX 2147483647
time_t a = TIME_MAX;
time_t b = TIME_MAX;
time_t
add_noopt(time_t a, time_t b) __attribute__((optnone))
{
a += b;
if (a < b)
a = TIME_MAX;
return a;
}
time_t
add_withopt(time_t a, time_t b)
{
a += b;
if (a < b)
a = TIME_MAX;
return a;
}
time_t
add_rephrased(time_t a, time_t b)
{
if (a < 0 || a > TIME_MAX - b)
a = TIME_MAX;
else
a += b;
return a;
}
int
main(int argc, char **argv)
{
printf("no opt:0x%08x\n", add_noopt(a, b));
printf("with opt: 0x%08x\n", add_withopt(a, b));
printf("rephrased: 0x%08x\n", add_rephrased(a, b));
}
Should this be reported to the clang folks? Or is this to be expected when
abusing integer overflows this way?
Also: The underlying problem is the fact that time_t is a 32 bit signed int.
Any pointers as to a general method of resolving these time_t issues?
Regards,
Nick Hibma
n...@van-laarhoven.org
-- Open Source: We stand on the shoulders of giants.
signature.asc
Description: Message signed with OpenPGP
Re: How much memory do I need for buildworld?
Nov 22 16:55:13 mercury kernel: swap_pager: out of swap space Nov 22 16:55:13 mercury kernel: swap_pager_getswapspace(16): failed Nov 22 16:55:13 mercury kernel: pid 22841 (tblgen), uid 0, was killed: out of swap space This machine has 256MB of RAM and one 64MB swap partition. This is most likely the problem: you need more RAM for this particular instance of tblgen. On my -CURRENT i386 box, it takes ~369MiB of RSS to build the X86 disassembler tables. I'm surprised you didn't run into OOM problems earlier, with so little memory. For such router like machines, it is obviously easier to do the build on a fast desktop machine, then install over NFS, or rsync /usr/src and /usr/obj to the target machine. I suggest you have a look at NanoBSD in /usr/src/tools/tools/nanobsd.sh. It will build a disk image for you in roughly 1 hour on a fast machine with 4+ processors by doing a complete world. It allows you to regenerate the image and update a running image easily. If you keep your changes separated in /cfg you will find that you can actually work really quickly in this setup (even though not being able to install packages on the image directly is sometimes a bit of a nuisance). We've wrapped that script with a lot of our own stuff and go from initial config to running in VM in less than 5 minutes, 2.5 minutes for an update after that (using an SSD on the host and FreeBSD in a single processor VM generating the image). Nick signature.asc Description: Message signed with OpenPGP using GPGMail
Huawei E3272 tester needed
Hi, Is there someone who is able to test support for the Huawei E3272 card with CURRENT after 269584? I have not been able to confirm that it works. Thanks in advance. Nick The change: Author: n_hibma Date: Tue Aug 5 12:08:50 2014 New Revision: 269584 URL: http://svnweb.freebsd.org/changeset/base/269584 Log: Add support for Huawei E3272 modems which are supported by the CDC ethernet class. Note: This is untested as I do not have a device like this. That is reflected in the MFC timeout. PR:192345 Submitted by: rozhuk.im gmail.com MFC after: 4 weeks Modified: head/sys/dev/usb/net/if_cdce.c head/sys/dev/usb/usbdevs ___ 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
CDC-WDM driver (4G modems)
Folks, Hans-Petter, Is anyone aware of an effort to create support for QMI based 4G modems? The following parts need to be implemented I think: - CDC-WDM support - Wrapper driver to access QMI devices as WDM? - libqmi port to FreeBSD This would support any modem from Telit, Sierra Wireless, Option, etc. that works with the Qualcomm chipsets. If you look in the cdc-wdm qmi driver in Linux, it is a long list. I could not find any mention of FreeBSD and QMI on the same page, so I assume no one is working on it. Nick Hibma ___ 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: Feature Proposal: Transparent upgrade of crypt() algorithms
On 28 Feb 2014, at 02:14, Allan Jude free...@allanjude.com wrote: With r262501 (http://svnweb.freebsd.org/base?view=revisionrevision=262501) importing the upgraded bcrypt from OpenBSD and eventually changing the default identifier for bcrypt to $2b$ it reminded me of a feature that is often seen in Forum software and other web apps. … This would make it much easier to transition a very large userbase from md5crypt to bcrypt or sha512crypt, rather than expiring the passwords or something. The sleeping accounts won’t be upgraded, so be left at the ‘insecure’ algorithm. I do see the point of automatic updating of password hashes for a newer algorithm, but ‘not needing expiry’ isn’t the right argument. It is actually an argument opposing your change! What you probably meant was: don’t hassle users with the change in algorithm, possibly only the users that haven’t ever logged in after 6 months. Nick signature.asc Description: Message signed with OpenPGP using GPGMail
Re: RFC: support for first boot rc.d scripts
Yes, it's hard to store state on diskless systems... but I figured that anyone building a diskless system would know to not create a run firstboot scripts marker. And not all embedded systems are diskless... The embedded systems we create at $work have readonly root and mfs /var, but we do have writable storage on another filesystem. It would work for us (not that we need this feature right now) if there were an rcvar that pointed to the marker file. Of course to make it work, something would have to get the alternate filesystem mounted early enough to be useful (that is something we do already with a custom rc script). Indeed... the way my patch currently does things, it looks for the firstboot sentinel at the start of /etc/rc, which means it *has* to be on /. Making the path an rcvar is a good idea (updated patch attached) but we still need some way to re-probe for that file after mounting extra filesystems. In many cases a simple test -f /firstboot bla_enable='YES' || bla_enable='NO' rm -f /firstboot in your specific rc.d script would suffice. Or for installing packages: for pkg in $PKGS; do if ! pkg_info $pkg-'[0-9]*' /dev/null 21; then pkg_add /some/dir/$pkg.txz fi done I am not quite sure why we need /firstboot handling in /etc/rc. Perhaps it is a better idea to make this more generic, to move the rc.d script containing a 'runonce' keyword to a subdirectory as the last step in rc (or make that an rc.d script in itself!). That way you could consider moving it back if you need to re-run it. Or have an rc.d script setup something like a database after installing a package by creating a rc.d runonce script. Default dir could be ./run-once relative to the rc.d dir it is in, configurable through runonce_directory . Note: The move would need to be done at the very end of rc.d to prevent rcorder returning a different ordering and skipping scripts because of that. Nick ___ 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: support for first boot rc.d scripts
Colin, Sounds useful: We have nanobsd images that configure a hard disk if present, but obviously only need to be run once. However: NanoBSD stores uses a memory disk for /etc and stores it's permanent scripts in /conf/* (/etc/rc.initdiskless) and/or /cfg (NanoBSD) so I doubt whether the 'embedded systems' argument is of much use, as deleting the script or flagging 'firstboot' is non-permanent. Nick Hibma n...@van-laarhoven.org Want to feel like going on a holiday tomorrow? Try GTD. On 14 Oct 2013, at 00:58, Colin Percival cperc...@freebsd.org wrote: Hi all, I've attached a very simple patch which makes /etc/rc: 1. Skip any rc.d scripts with the firstboot keyword if /var/db/firstboot does not exist, 2. If /var/db/firstboot and /var/db/firstboot-reboot exist after running rc.d scripts, reboot. 3. Delete /var/db/firstboot (and firstboot-reboot) after the first boot. The purpose of this is to support run on first boot rc.d scripts. These can be useful for both virtual machines and embedded systems; unlike conventional desktops and servers, these may have a lengthy gap between installing and turning on the system. As examples of what such scripts could do: * In Amazon EC2, I use a first boot script to download an SSH public key from EC2 so that users can log in to newly provisioned EC2 instances. * Now that (starting from 10.0-BETA1) it is possible to use FreeBSD Update to update everything on EC2 instances, I'm planning on writing a script which runs 'freebsd-update fetch install' when the system first boots, and then reboots if there were updates installed. (I imagine this would be useful to other embedded / VM providers too.) * Once packages are provided (properly) for 10.0 I'd like to allow people to specify a list of packages they want installed onto an EC2 instance and have them downloaded and installed when the EC2 instance launches. I'd like to get this into HEAD in the near future in the hope that I can convince re@ that this is a simple enough (and safe enough) change to merge before 10.0-RELEASE. Comments? -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid firstboot.patch___ 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 ___ 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
route -blackhole option behaves differently on localhost from a normal host
After doing a
route add host 127.0.0.1 -blackhole
on a FreeBSD 8.3 host I noticed that nc host 80 would instantly return with
ENETUNRACH, instead of timing out, while blackhole routing to a real host would
time out. Checking in CURRENT (october 2012) reveals the same behaviour:
# netstat -nr
Routing tables
Internet:
DestinationGatewayFlagsRefs Use Netif Expire
default10.0.2.2 UGS 01vtnet0
10.0.2.0/24link#1 U 0 1295vtnet0
10.0.2.15 link#1 UHS 00lo0
10.0.3.0/24link#2 U 00vtnet1
10.0.3.4 link#2 UHS 00lo0
127.0.0.1 link#3 UH 0 1479lo0
Internet6:
Destination Gateway Flags
Netif Expire
::/96 ::1 UGRS
lo0
::1 link#3UH
lo0
:::0.0.0.0/96 ::1 UGRS
lo0
fe80::/10 ::1 UGRS
lo0
fe80::%vtnet1/64 link#2U
vtnet1
fe80::a00:27ff:fea4:1a9a%vtnet1 link#2UHS
lo0
fe80::%lo0/64 link#3U
lo0
fe80::1%lo0 link#3UHS
lo0
ff01::%vtnet1/32 fe80::a00:27ff:fea4:1a9a%vtnet1 U
vtnet1
ff01::%lo0/32 ::1 U
lo0
ff02::/16 ::1 UGRS
lo0
ff02::%vtnet1/32 fe80::a00:27ff:fea4:1a9a%vtnet1 U
vtnet1
ff02::%lo0/32 ::1 U
lo0
# route add 4.2.2.1 127.0.0.1 -blackhole
add host 4.2.2.1: gateway 127.0.0.1
# route add 4.2.2.2 10.0.2.15 -blackhole
add host 4.2.2.2: gateway 10.0.2.15
# time nc -v -w 3 4.2.2.2 80
nc: connect to 4.2.2.2 port 80 (tcp) failed: Operation timed out
real 0m3.089s
user 0m0.000s
sys 0m0.014s
# time nc -v -w 3 4.2.2.1 80
nc: connect to 4.2.2.1 port 80 (tcp) failed: Network is unreachable
real 0m0.014s
user 0m0.000s
sys 0m0.014s
# uname -a
FreeBSD citske.localdomain 10.0-CURRENT FreeBSD 10.0-CURRENT #3 r241988M: Wed
Oct 24 15:21:27 CEST 2012
root@citske.localdomain:/usr/obj/usr/src/sys/CITSKE i386
A quick grep -r through the kernel did not provide me with any obvious mistake,
but a colleague suggested that for localhost an if 'statement' like the
following might be missing somewhere:
if (rt rt-rt_flags (RTF_REJECT|RTF_BLACKHOLE)) {
m_freem(m);
return (rt-rt_flags RTF_BLACKHOLE ? 0 :
rt-rt_flags RTF_HOST ? EHOSTUNREACH : ENETUNREACH);
}
Any pointers would be appreciated
Nick Hibma
n...@van-laarhoven.org
GTD: Time management for chaotic people.
___
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: No console, not even serial, does not work (init fails) - init from HEAD works
[feels like I am talking to myself in this thread ...]
After copying the /usr/src/sbin/init/ directory from HEAD to 8.3-RELEASE and
building init there (without changes), things started working again, and the
image now succesfully boots. Thanks for that.
The downside of this approach is the lack of logging of the output of the
console output. I've tried quickly to throw together a 'null' console which
would make the console output at least appear in the output of 'dmesg -a', but
that change requires a tty device, which I couldn' be asked to throw together.
Ed was going to think this over, especially because a null console might come
in handy in jails.
Hope this is of use to anyone.
Nick Hibma
n...@van-laarhoven.org
How many todos are on YOUR To Do lists? - GTD
On 19 Feb 2013, at 10:03, Nick Hibma wrote:
Ed sent me a answer to my ramblings:
It is indeed true that init(8) is a bit picky when you don't have a
console. If /dev/console cannot be opened, init(8) will just break
completely. This has been fixed in FreeBSD -HEAD, where I've extended
init(8) to handle this gracefully, specifically for cases where you
have hardware without a console or potentially want to run init(8) in
a jail (though we're not there yet).
http://svnweb.freebsd.org/base?view=revisionrevision=232977
I'll try that, and will follow up here.
Nick Hibma
n...@van-laarhoven.org
Collect, process, organize, review and do. - GTD
On 18 Feb 2013, at 20:30, Nick Hibma n...@van-laarhoven.org wrote:
We run our NanoBSD images on Soekris and ALIX hardware. In some cases we
need all available serial ports for other hardware like GPS, and modems. The
boards have no video, so with all serial ports unavailable as a console no
other console is available.
The problem is that FreeBSD does not handle well the case where there is no
console at all:
1) http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/102515
fsck_ufs crashes (6.1-STABLE). Because of the unitialised console libc
somehow gets corrupted and crashes fsck_ufs. This problem can be
circumvented by replacing 'fsck -p' with 'fsck /dev/null /dev/null'.
2) In 8.3-RELEASE init exits prematurely because it cannot open /dev/console
for reading and writing in setctty(). Removing the calls to _exit(1) in that
function makes the boot complete. I haven't checked whether the fsck_ufs
problem still appears as our builds run with a patched rc.d script.
As far as I can see this is still a problem in CURRENT.
My attempt at resolving this was to create a null terminal in
dev/null/null.c, see the patch below, but that did not work as expected.
After booting the system with a modified init the response to 'echo
/dev/console' was 'Device not configured'. I've added another CN_* priority
to make sure a null console does not take precedence over for example gdb
console.
Any pointers as to who/how to resolve this issue? Any reason why the null
console approach does not work?
Nick Hibma
n...@van-laarhoven.org
GTD: Time management for chaotic people.
Index: /usr/src/sys/sys/cons.h
===
--- /usr/src/sys/sys/cons.h (revision 242660)
+++ /usr/src/sys/sys/cons.h (working copy)
@@ -69,10 +69,11 @@
/* values for cn_pri - reflect our policy for console selection */
#define CN_DEAD 0 /* device doesn't exist */
-#define CN_LOW 1 /* device is a last restort only */
-#define CN_NORMAL 2 /* device exists but is nothing special */
-#define CN_INTERNAL 3 /* internal bit-mapped display */
-#define CN_REMOTE 4 /* serial interface with remote bit set */
+#define CN_NULL 1 /* no console at all */
+#define CN_LOW 2 /* device is a last restort only */
+#define CN_NORMAL 3 /* device exists but is nothing special */
+#define CN_INTERNAL 4 /* internal bit-mapped display */
+#define CN_REMOTE 5 /* serial interface with remote bit set */
/* Values for cn_flags. */
#define CN_FLAG_NODEBUG 0x0001 /* Not supported with debugger.
*/
Index: /usr/src/sys/dev/null/null.c
===
--- /usr/src/sys/dev/null/null.c (revision 242660)
+++ /usr/src/sys/dev/null/null.c (working copy)
@@ -41,6 +41,9 @@
#include sys/bus.h
#include sys/filio.h
+#include sys/cons.h
+#include sys/consio.h
+
#include machine/bus.h
/* For use with destroy_dev(9). */
@@ -173,3 +176,45 @@
DEV_MODULE(null, null_modevent, NULL);
MODULE_VERSION(null, 1);
+
+static cn_probe_t null_cnprobe;
+static cn_init_t null_cninit;
+static cn_term_t null_cnterm;
+static cn_getc_t null_cngetc;
+static cn_putc_t null_cnputc;
+
+CONSOLE_DRIVER(null);
+
+static void
+null_cnprobe(struct consdev *cp)
+{
+sprintf(cp-cn_name, null);
+cp-cn_pri = CN_NULL;
+}
+
+static
Re: No console, not even serial, does not work (init fails)
Ed sent me a answer to my ramblings:
It is indeed true that init(8) is a bit picky when you don't have a
console. If /dev/console cannot be opened, init(8) will just break
completely. This has been fixed in FreeBSD -HEAD, where I've extended
init(8) to handle this gracefully, specifically for cases where you
have hardware without a console or potentially want to run init(8) in
a jail (though we're not there yet).
http://svnweb.freebsd.org/base?view=revisionrevision=232977
I'll try that, and will follow up here.
Nick Hibma
n...@van-laarhoven.org
Collect, process, organize, review and do. - GTD
On 18 Feb 2013, at 20:30, Nick Hibma n...@van-laarhoven.org wrote:
We run our NanoBSD images on Soekris and ALIX hardware. In some cases we need
all available serial ports for other hardware like GPS, and modems. The
boards have no video, so with all serial ports unavailable as a console no
other console is available.
The problem is that FreeBSD does not handle well the case where there is no
console at all:
1) http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/102515
fsck_ufs crashes (6.1-STABLE). Because of the unitialised console libc
somehow gets corrupted and crashes fsck_ufs. This problem can be circumvented
by replacing 'fsck -p' with 'fsck /dev/null /dev/null'.
2) In 8.3-RELEASE init exits prematurely because it cannot open /dev/console
for reading and writing in setctty(). Removing the calls to _exit(1) in that
function makes the boot complete. I haven't checked whether the fsck_ufs
problem still appears as our builds run with a patched rc.d script.
As far as I can see this is still a problem in CURRENT.
My attempt at resolving this was to create a null terminal in
dev/null/null.c, see the patch below, but that did not work as expected.
After booting the system with a modified init the response to 'echo
/dev/console' was 'Device not configured'. I've added another CN_* priority
to make sure a null console does not take precedence over for example gdb
console.
Any pointers as to who/how to resolve this issue? Any reason why the null
console approach does not work?
Nick Hibma
n...@van-laarhoven.org
GTD: Time management for chaotic people.
Index: /usr/src/sys/sys/cons.h
===
--- /usr/src/sys/sys/cons.h (revision 242660)
+++ /usr/src/sys/sys/cons.h (working copy)
@@ -69,10 +69,11 @@
/* values for cn_pri - reflect our policy for console selection */
#define CN_DEAD 0 /* device doesn't exist */
-#define CN_LOW 1 /* device is a last restort only */
-#define CN_NORMAL2 /* device exists but is nothing special */
-#define CN_INTERNAL 3 /* internal bit-mapped display */
-#define CN_REMOTE4 /* serial interface with remote bit set */
+#define CN_NULL 1 /* no console at all */
+#define CN_LOW 2 /* device is a last restort only */
+#define CN_NORMAL3 /* device exists but is nothing special */
+#define CN_INTERNAL 4 /* internal bit-mapped display */
+#define CN_REMOTE5 /* serial interface with remote bit set */
/* Values for cn_flags. */
#define CN_FLAG_NODEBUG 0x0001 /* Not supported with debugger.
*/
Index: /usr/src/sys/dev/null/null.c
===
--- /usr/src/sys/dev/null/null.c (revision 242660)
+++ /usr/src/sys/dev/null/null.c (working copy)
@@ -41,6 +41,9 @@
#include sys/bus.h
#include sys/filio.h
+#include sys/cons.h
+#include sys/consio.h
+
#include machine/bus.h
/* For use with destroy_dev(9). */
@@ -173,3 +176,45 @@
DEV_MODULE(null, null_modevent, NULL);
MODULE_VERSION(null, 1);
+
+static cn_probe_t null_cnprobe;
+static cn_init_t null_cninit;
+static cn_term_t null_cnterm;
+static cn_getc_t null_cngetc;
+static cn_putc_t null_cnputc;
+
+CONSOLE_DRIVER(null);
+
+static void
+null_cnprobe(struct consdev *cp)
+{
+sprintf(cp-cn_name, null);
+cp-cn_pri = CN_NULL;
+}
+
+static void
+null_cninit(struct consdev *cp)
+{
+}
+
+
+static void
+null_cnputc(struct consdev *cp, int c)
+{
+ (void) cp;
+
+ (void) c;
+}
+
+static int
+null_cngetc(struct consdev * cp)
+{
+ (void) cp;
+
+ return -1;
+}
+
+static void
+null_cnterm(struct consdev * cp)
+{
+}
___
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
No console, not even serial, does not work (init fails)
We run our NanoBSD images on Soekris and ALIX hardware. In some cases we need
all available serial ports for other hardware like GPS, and modems. The boards
have no video, so with all serial ports unavailable as a console no other
console is available.
The problem is that FreeBSD does not handle well the case where there is no
console at all:
1) http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/102515
fsck_ufs crashes (6.1-STABLE). Because of the unitialised console libc somehow
gets corrupted and crashes fsck_ufs. This problem can be circumvented by
replacing 'fsck -p' with 'fsck /dev/null /dev/null'.
2) In 8.3-RELEASE init exits prematurely because it cannot open /dev/console
for reading and writing in setctty(). Removing the calls to _exit(1) in that
function makes the boot complete. I haven't checked whether the fsck_ufs
problem still appears as our builds run with a patched rc.d script.
As far as I can see this is still a problem in CURRENT.
My attempt at resolving this was to create a null terminal in dev/null/null.c,
see the patch below, but that did not work as expected. After booting the
system with a modified init the response to 'echo /dev/console' was 'Device
not configured'. I've added another CN_* priority to make sure a null console
does not take precedence over for example gdb console.
Any pointers as to who/how to resolve this issue? Any reason why the null
console approach does not work?
Nick Hibma
n...@van-laarhoven.org
GTD: Time management for chaotic people.
Index: /usr/src/sys/sys/cons.h
===
--- /usr/src/sys/sys/cons.h (revision 242660)
+++ /usr/src/sys/sys/cons.h (working copy)
@@ -69,10 +69,11 @@
/* values for cn_pri - reflect our policy for console selection */
#defineCN_DEAD 0 /* device doesn't exist */
-#define CN_LOW 1 /* device is a last restort only */
-#define CN_NORMAL 2 /* device exists but is nothing special */
-#define CN_INTERNAL3 /* internal bit-mapped display */
-#define CN_REMOTE 4 /* serial interface with remote bit set */
+#define CN_NULL1 /* no console at all */
+#define CN_LOW 2 /* device is a last restort only */
+#define CN_NORMAL 3 /* device exists but is nothing special */
+#define CN_INTERNAL4 /* internal bit-mapped display */
+#define CN_REMOTE 5 /* serial interface with remote bit set */
/* Values for cn_flags. */
#defineCN_FLAG_NODEBUG 0x0001 /* Not supported with debugger.
*/
Index: /usr/src/sys/dev/null/null.c
===
--- /usr/src/sys/dev/null/null.c(revision 242660)
+++ /usr/src/sys/dev/null/null.c(working copy)
@@ -41,6 +41,9 @@
#include sys/bus.h
#include sys/filio.h
+#include sys/cons.h
+#include sys/consio.h
+
#include machine/bus.h
/* For use with destroy_dev(9). */
@@ -173,3 +176,45 @@
DEV_MODULE(null, null_modevent, NULL);
MODULE_VERSION(null, 1);
+
+static cn_probe_t null_cnprobe;
+static cn_init_t null_cninit;
+static cn_term_t null_cnterm;
+static cn_getc_t null_cngetc;
+static cn_putc_t null_cnputc;
+
+CONSOLE_DRIVER(null);
+
+static void
+null_cnprobe(struct consdev *cp)
+{
+sprintf(cp-cn_name, null);
+cp-cn_pri = CN_NULL;
+}
+
+static void
+null_cninit(struct consdev *cp)
+{
+}
+
+
+static void
+null_cnputc(struct consdev *cp, int c)
+{
+ (void) cp;
+
+ (void) c;
+}
+
+static int
+null_cngetc(struct consdev * cp)
+{
+ (void) cp;
+
+ return -1;
+}
+
+static void
+null_cnterm(struct consdev * cp)
+{
+}
___
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: use_generic and usb probing
Well, I think that that's what probe priorities actually for. I also think that typically ivars should be set by a bus driver. So maybe it's not such a good idea to pass data from probe to attach via ivars in child drivers. But I could be mistaken about that. Practically speaking, you most likely don't have to worry about that for drivers that return BUS_PROBE_SPECIFIC (=0) from their probe methods. And there is only a few generic drivers that can be handled on a case by case basis. Newbus priorities where specifically implemented on my request by Doug Rabson to cater for fallback attachments: usb.h (the old code) contained a list of priorities. ugen had the lowest priority and attached if no one else did. An example was a keyboard with a built-in mouse on one interface. It would be attached by either mouse or keyboard but not both. An additional driver could probide both devices. We ended up implementing that differently though: attachment to interfaces instead of devices. A probe should not pass any information to the attach phase if it can at all avoid it. Or at least that is the assumption. If a driver needs info in both phases, it needs to regenerate it again. The fact that usb_probe is called again is a kludge, specifically for the description. I guess that documenting this kludge and updating the comment to state this fact would be sufficient to solve the problem. Nick___ 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: USB related panic on 8.2-PRERELEASE
But we will continue the saga about this strange USB modem, if no objections from your side :) Is it possible to apply some quirk or some another workaround which will solve the issue with endless USB_ERR_STALLED reported while it trying to attach its builtin cardreader? Nick, do you have any hints on this? It says in the messages log (a view messages ago) that it does not support GET MAX LUN. You can quirk that: While the device is attached use the following command: usbconfig -d ugenX.Y add_quirk UQ_MSC_NO_GETMAXLUN where ugenX.Y is the ugen device for the device that causes you trouble. usbconfig will add a quirk using the PID/VID/RID for the device it finds at that location. If that works, let me know, and I will commit the quirk into the quirk table. Nick___ 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: [Patch] libfetch - closing the cached FTP connection
Mark,
My 2 cents: Isn't it more appropriate to set FD_CLOEXEC on the fd?
fcntl(fd, F_SETFD, FD_CLOEXEC);
It doesn't sound like you ever want to have a cached connection be copied into
the child. Mum and child calling daddy using the same phone line isn't going to
make the conversation any easier for daddy.
Cheers,
Nick
On 25 Oct 2010, at 01:16, Mark Johnston wrote:
Hello,
We've run into problems with pkg_add because of some caching behaviour
in libfetch. Specifically, after an FTP transfer, a connection to the
FTP server is held open by the cached_connection pointer in ftp.c. Thus,
if one requests a file with fetchGetFTP() and later closes the
connection with fclose(), a socket is still held open, and the
descriptor is copied to any child processes.
What was apparently happening was that we were using pkg_add to install
a package whose install script started a daemon, which consequently kept
open a connection to our FTP server. This is fixed in our tree with a
closefrom(2) in pkg_install at an appropriate point, but I thought that
libfetch should provide some way of forcing a close on the cached
connection so that the above hack isn't necessary.
My solution is provided in a patch below. It's not particularly elegant,
but I can't see a better way to go about it. I was hoping to get some
feedback and to see if anyone can come up with a better approach. I'll
also update the libfetch man page if the patch below is acceptable.
Thanks,
-Mark
diff --git a/lib/libfetch/fetch.h b/lib/libfetch/fetch.h
index 11a3f77..d379e63 100644
--- a/lib/libfetch/fetch.h
+++ b/lib/libfetch/fetch.h
@@ -109,6 +109,7 @@ FILE *fetchGetFTP(struct url *, const char
*);
FILE *fetchPutFTP(struct url *, const char *);
intfetchStatFTP(struct url *, struct url_stat *, const char *);
struct url_ent*fetchListFTP(struct url *, const char *);
+void fetchCloseCachedFTP();
/* Generic functions */
FILE *fetchXGetURL(const char *, struct url_stat *, const char *);
diff --git a/lib/libfetch/ftp.c b/lib/libfetch/ftp.c
index 0983a76..746ad54 100644
--- a/lib/libfetch/ftp.c
+++ b/lib/libfetch/ftp.c
@@ -1204,3 +1204,12 @@ fetchListFTP(struct url *url __unused, const char
*flags __unused)
warnx(fetchListFTP(): not implemented);
return (NULL);
}
+
+/*
+ * Force close the cached connection.
+ */
+void
+fetchCloseCachedFTP()
+{
+ ftp_disconnect(cached_connection);
+}
diff --git a/usr.sbin/pkg_install/lib/url.c b/usr.sbin/pkg_install/lib/url.c
index 914ce39..68f31bb 100644
--- a/usr.sbin/pkg_install/lib/url.c
+++ b/usr.sbin/pkg_install/lib/url.c
@@ -163,5 +163,6 @@ fileGetURL(const char *base, const char *spec, int
keep_package)
printf(tar command returns %d status\n, WEXITSTATUS(pstat));
if (rp (isatty(0) || Verbose))
printf( Done.\n);
+fetchCloseCachedFTP();
return rp;
}
___
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
___
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: [Patch] libfetch - closing the cached FTP connection
I think using fcntl is nicer than having a close the cached connection function, but I don't think I can get around this problem without changing something in libfetch. I think libfetch should set the Close-On-Exec flag. It's wrong to have these files propagate to children. Nick___ 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: [PATCH] usbdevs {-1.5}
[EMAIL PROTECTED] Current, I've gone through the USB hardware that I had laying around and added a series of entries in usbdevs. I submitted a couple of entries a while ago, but I guess the email got lost in the noise. Who should I contact about getting this committed? Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umass CF geometry problems, was Re: fdisk -BI ob clean diskbroken
Well the short version of the problem is that fdisk -BI disk works on -stable to get a FreeBSD partition on the Compact Flash. This does not work on -current anymore. I have traced that back to the commit in umass.c rev 1.61 that removed the fake geometry setting and just leave the cylinders, heads and sectors_per_track zero. This cause fdisk to coredump with a floating point error. Hm, strange. I would think that a compact flasg is an ATAPI over CBI device (see attach message in your dmesg). If that is the case, the 'fake setting' was not done in STABLE either and I would expect the problem to be somewhere else. But that would contradict your research. Nick To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: umass CF geometry problems, was Re: fdisk -BI ob clean diskbroken
Let's work on the 'proper' solution first. What SCSI commands are suitable for getting the geometry, generically on a device? Nick fdisk likely should do something sane in the face of such insanity, but it is unclear what and fdisk is a royal pita to work on anyway :-( Warner -- [EMAIL PROTECTED] http://www.van-laarhoven.org/ [EMAIL PROTECTED]http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: umass CF geometry problems, was Re: fdisk -BI ob clean diskbroken
Hm, the only one that does something different is the iir/iir.c driver.
I guess the best thing is to just copy what's in the aha driver.
Nick
Let's work on the 'proper' solution first.
What SCSI commands are suitable for getting the geometry, generically
on a device?
Hmmm, I made an interesting discovery. I searched through some of the
scsi drivers, sys/dev/{aha|ahb|aic*|sym}, looking for XPT_CALC_GEOMETRY
and they all fake the geometry. :-/
fdisk likely should do something sane in the face of such insanity,
but it is unclear what and fdisk is a royal pita to work on anyway :-(
John
--
[EMAIL PROTECTED] http://www.van-laarhoven.org/
[EMAIL PROTECTED]http://www.etla.net/~n_hibma/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: umass CF geometry problems, was Re: fdisk -BI ob clean diskbroken
That wasn't quite what I meant. I was referring to SCSI commands that are sent to the device that return info that would be usable as the number of heads and cylinders. But I guess faking them like the ah[abc] drivers do will work, as this is what many systems are already running with. Nick See XPT_CALC_GEOMETRY in /sys/dev/aic7xxx/aic7xxx_osm.c On Mon, 4 Nov 2002, Nick Hibma wrote: Let's work on the 'proper' solution first. What SCSI commands are suitable for getting the geometry, generically on a device? Nick fdisk likely should do something sane in the face of such insanity, but it is unclear what and fdisk is a royal pita to work on anyway :-( Warner -- [EMAIL PROTECTED] http://www.van-laarhoven.org/ [EMAIL PROTECTED]http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: umass CF geometry problems, was Re: fdisk -BI ob clean diskbroken
USB is only the transport. It doesn't add or remove functionality (the only exception being probing for LUNs on CBI devices). If you want to determine the geometry you will have to do this through SCSI commands. I was hoping that the CAM code would be smart enough to request the details from the drive itself, but perhaps there is a good reason for asking the controller for this. It did work without, so it hasn't been implemented yet. Feel free to suggest a SCSI command together with the logic. What is the GET_GEOMETRY used for anyway? Nick In message: [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: : We should obviously fix it. I have no idea what is possible in USB : devices in this respect. Nor do I. Maybe there's some SCSI command that we can send that is well defined enough to work often enough. However, I'm not clueful enough about SCSI to know if this can be done (likely reading some mode page will do it in real SCSI), nor about USB's mass storage devices, nor about all the wonderful and weird variations that one might find in the wild... Warner -- [EMAIL PROTECTED] http://www.van-laarhoven.org/ [EMAIL PROTECTED]http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
making make load work for /sys/modules/*
At the moment 'make load' does not work in /sys/modules. The attached
patch fixes that by using .OBJDIR instead of .CURDIR as the absolute
path to find the module at:
heidi:toor# make
Warning: Object directory not changed from original /usr/src-current/sys/modules/umass
...
heidi:toor# make load
/sbin/kldload -v /usr/src-current/sys/modules/umass/umass.ko
Loaded /usr/src-current/sys/modules/umass/umass.ko, id=5
...
heidi:toor# make obj
/usr/obj/usr/src-current/sys/modules/umass created for
/usr/src-current/sys/modules/umass
heidi:toor# make
...
heidi:toor# make load
/sbin/kldload -v /usr/src-current/sys/modules/umass/umass.ko
kldload: can't load /usr/src-current/sys/modules/umass/umass.ko: No such file or
directory
*** Error code 1
Stop in /usr/src-current/sys/modules/umass.
After changing .CURDIR to .OBJDIR it selects the correct module
depending on whether it was created in the MAKEOBJDIR directory or not:
heidi:toor# make
Warning: Object directory not changed from original /usr/src-current/sys/modules/umass
...
heidi:toor# make load
/sbin/kldload -v /usr/src-current/sys/modules/umass/umass.ko
Loaded /usr/src-current/sys/modules/umass/umass.ko, id=5
...
heidi:toor# make obj
/usr/obj/usr/src-current/sys/modules/umass created for
/usr/src-current/sys/modules/umass
heidi:toor# make
...
heidi:toor# make load
/sbin/kldload -v /usr/obj/usr/src-current/sys/modules/umass/umass.ko
Loaded /usr/obj/usr/src-current/sys/modules/umass/umass.ko, id=5
Any objections to the attached patch? Any reason to wait for a system
makefiles guru?
Nick
--
[EMAIL PROTECTED] http://www.van-laarhoven.org/
[EMAIL PROTECTED]http://www.etla.net/~n_hibma/
Index: kmod.mk
===
RCS file: /home/ncvs/src/sys/conf/kmod.mk,v
retrieving revision 1.124
diff -u -r1.124 kmod.mk
--- kmod.mk 14 May 2002 07:49:12 - 1.124
+++ kmod.mk 16 Jun 2002 18:18:17 -
@@ -278,7 +278,7 @@
.if !target(load)
load: ${PROG}
- ${KMODLOAD} -v ${.CURDIR}/${KMOD}.ko
+ ${KMODLOAD} -v ${.OBJDIR}/${KMOD}.ko
.endif
.if !target(unload)
Re: gdb52 patch for your .gdbinit files
As you can see, the patch is trivial, so I have no clue why this wasn't left alone when they modified symfile.c. If I can be bothered I'll submit it to them. Hmm. Looking at this patch, it seems it's complaining about being handed a hex value where it's looking for an address. I'd guess that this is in the wrong place. Where does it happen in the macros? Have a look at the gdb sources in FreeBSD-CURRENT and notice the fact that they removed the call to parse_and_eval_address and rolled their own. An address like $file-address+0xabcdef should be possible, but isn't in the distribution of 5.2. After the patch it is. i've filed the patch with an already open bug report on this on GNU gdb 5.2 Nick Greg # diff -wu gdb-5.2/gdb/symfile.c~ gdb-5.2/gdb/symfile.c --- gdb-5.2/gdb/symfile.c~ Tue May 28 15:51:37 2002 +++ gdb-5.2/gdb/symfile.c Tue May 28 15:51:06 2002 @@ -1546,11 +1546,15 @@ char *val = sect_opts[i].value; char *sec = sect_opts[i].name; +#ifdef 0 val = sect_opts[i].value; if (val[0] == '0' val[1] == 'x') addr = strtoul (val+2, NULL, 16); else addr = strtoul (val, NULL, 10); +#else + addr = parse_and_eval_address(val); +#endif /* Here we store the section offsets in the order they were entered on the command line. */ -- See complete headers for address and phone numbers -- [EMAIL PROTECTED] http://www.van-laarhoven.org/ [EMAIL PROTECTED]http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
gdb52 patch for your .gdbinit files
I'm using a derivative of the .gdbinit.vinum files that is available in the modules/vinum directory. For them to work the following patch is needed in gdb52. As you can see, the patch is trivial, so I have no clue why this wasn't left alone when they modified symfile.c. If I can be bothered I'll submit it to them. Nick # diff -wu gdb-5.2/gdb/symfile.c~ gdb-5.2/gdb/symfile.c --- gdb-5.2/gdb/symfile.c~ Tue May 28 15:51:37 2002 +++ gdb-5.2/gdb/symfile.c Tue May 28 15:51:06 2002 @@ -1546,11 +1546,15 @@ char *val = sect_opts[i].value; char *sec = sect_opts[i].name; +#ifdef 0 val = sect_opts[i].value; if (val[0] == '0' val[1] == 'x') addr = strtoul (val+2, NULL, 16); else addr = strtoul (val, NULL, 10); +#else + addr = parse_and_eval_address(val); +#endif /* Here we store the section offsets in the order they were entered on the command line. */ -- [EMAIL PROTECTED] http://www.van-laarhoven.org/ [EMAIL PROTECTED]http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gdb52 patch for your .gdbinit files
Doh! me bad, I didn't include an example:
The attached .gdbinit loads the symbols from a module, but needs the
start address of the .text section.
add-symbol-file filename address
address cannot be an expression in gdb5.2, just a simple address
('0x[0-9a-f]+' or '[0-9]+').
Nick
On Tue, 28 May 2002, Mark Peek wrote:
At 3:54 PM +0200 5/28/02, Nick Hibma wrote:
I'm using a derivative of the .gdbinit.vinum files that is available in
the modules/vinum directory. For them to work the following patch is
needed in gdb52.
As you can see, the patch is trivial, so I have no clue why this wasn't
left alone when they modified symfile.c. If I can be bothered I'll
submit it to them.
Nick
# diff -wu gdb-5.2/gdb/symfile.c~ gdb-5.2/gdb/symfile.c
--- gdb-5.2/gdb/symfile.c~ Tue May 28 15:51:37 2002
+++ gdb-5.2/gdb/symfile.c Tue May 28 15:51:06 2002
@@ -1546,11 +1546,15 @@
char *val = sect_opts[i].value;
char *sec = sect_opts[i].name;
+#ifdef 0
val = sect_opts[i].value;
if (val[0] == '0' val[1] == 'x')
addr = strtoul (val+2, NULL, 16);
else
addr = strtoul (val, NULL, 10);
+#else
+ addr = parse_and_eval_address(val);
+#endif
/* Here we store the section offsets in the order they were
entered on the command line. */
Nick,
Could you send me the relevant lines from your .gdbinit that exhibit
this problem? I'd like to understand why the above patch to gdb is
necessary.
Thanks!
Mark
--
[EMAIL PROTECTED] http://www.van-laarhoven.org/
[EMAIL PROTECTED]http://www.etla.net/~n_hibma/
define umass
set $file = linker_files.tqh_first
set $found = 0
while ($found == 0 $file != 0)
if ($file-filename[0] == 'u' $file-filename[1] == 'm' $file-filename[2] ==
'a' $file-filename[3] == 's' $file-filename[4] == 's' $file-filename[5] ==
'.' $file-filename[6] == 'k')
set $found = 1
else
set $file = $file-link.tqe_next
end
end
if ($found == 0)
echo umass not found in linker_files.\n
else
echo file=
print $file
shell /usr/bin/objdump --section-headers
/usr/obj/usr/src-current/sys/HEIDI/modules/usr/src-current/sys/modules/umass/umass.ko.debug
| grep ' .text' | awk '{print add-symbol-file
/usr/obj/usr/src-current/sys/HEIDI/modules/usr/src-current/sys/modules/umass/umass.ko.debug
\$file-address+0x $4}' /tmp/asf.umass
shell cat /tmp/asf.umass
source /tmp/asf.umass
#shell /bin/rm /tmp/asf.umass
end
end
document umass
Find the load address of umass in the kernel and add the symbols at this address
end
umass
New kernel option GDBSPEED (as in CONSPEED)?
CONSPEED is used for both console and gdb. This is a bit awkward because
it means that I have to run my kernel console on 9600 baud on my
diskless box. The attached patch fixes this by introducing another
variable GDBSPEED.
The patch makes the default for GDBSPEED 9600, so anyone who uses a
higher speed would need to set the variable to something sensible
afterwards. Would that require an entry in UPDATING?
Is there any documentation that needs to be updated because of this
change (I couldn't find anything that mentioned CONSPEED wrt gdb in
either src/ or doc/)
Any objections?
Nick
--
[EMAIL PROTECTED] http://www.van-laarhoven.org/
[EMAIL PROTECTED]http://www.etla.net/~n_hibma/
Index: sys/conf/options.i386
===
RCS file: /home/ncvs/src/sys/conf/options.i386,v
retrieving revision 1.170
diff -u -r1.170 options.i386
--- sys/conf/options.i386 16 May 2002 21:23:40 - 1.170
+++ sys/conf/options.i386 23 May 2002 19:38:42 -
@@ -15,6 +15,7 @@
AUTO_EOI_1 opt_auto_eoi.h
AUTO_EOI_2 opt_auto_eoi.h
CONSPEED opt_comconsole.h
+GDBSPEED opt_comconsole.h
I586_PMC_GUPROFopt_i586_guprof.h
WLCACHEopt_wavelan.h
WLDEBUGopt_wavelan.h
Index: sys/conf/options.pc98
===
RCS file: /home/ncvs/src/sys/conf/options.pc98,v
retrieving revision 1.145
diff -u -r1.145 options.pc98
--- sys/conf/options.pc98 19 May 2002 13:18:10 - 1.145
+++ sys/conf/options.pc98 23 May 2002 19:38:58 -
@@ -15,6 +15,7 @@
AUTO_EOI_1 opt_auto_eoi.h
AUTO_EOI_2 opt_auto_eoi.h
CONSPEED opt_comconsole.h
+GDBSPEED opt_comconsole.h
I586_PMC_GUPROFopt_i586_guprof.h
WLCACHEopt_wavelan.h
WLDEBUGopt_wavelan.h
Index: sys/dev/sio/sio.c
===
RCS file: /home/ncvs/src/sys/dev/sio/sio.c,v
retrieving revision 1.374
diff -u -r1.374 sio.c
--- sys/dev/sio/sio.c 26 Apr 2002 20:24:10 - 1.374
+++ sys/dev/sio/sio.c 26 May 2002 10:25:02 -
@@ -332,9 +332,7 @@
static volatile speed_tcomdefaultrate = CONSPEED;
static u_long comdefaultrclk = DEFAULT_RCLK;
SYSCTL_ULONG(_machdep, OID_AUTO, conrclk, CTLFLAG_RW, comdefaultrclk, 0, );
-#ifdef __alpha__
-static volatile speed_tgdbdefaultrate = CONSPEED;
-#endif
+static volatile speed_tgdbdefaultrate = GDBSPEED;
static u_int com_events; /* input chars + weighted output completions */
static Port_t siocniobase;
#ifndef __alpha__
@@ -418,6 +416,32 @@
0, 0, sysctl_machdep_comdefaultrate, I, );
/* TUNABLE_INT(machdep.conspeed, comdefaultrate); */
+#ifndef __alpha__
+/*
+ * Handle sysctl read/write requests for serial gdb speed
+ */
+
+static int
+sysctl_machdep_gdbdefaultrate(SYSCTL_HANDLER_ARGS)
+{
+ int error;
+ speed_t newspeed;
+
+ newspeed = gdbdefaultrate;
+
+ error = sysctl_handle_opaque(oidp, newspeed, sizeof newspeed, req);
+ if (error || !req-newptr)
+ return (error);
+
+ gdbdefaultrate = newspeed;
+
+ return 0;
+}
+
+SYSCTL_PROC(_machdep, OID_AUTO, gdbspeed, CTLTYPE_INT | CTLFLAG_RW,
+ 0, 0, sysctl_machdep_gdbdefaultrate, I, );
+#endif
+
#define SET_FLAG(dev, bit) device_set_flags(dev, device_get_flags(dev) | (bit))
#define CLR_FLAG(dev, bit) device_set_flags(dev, device_get_flags(dev) ~(bit))
@@ -3126,13 +3150,17 @@
Port_t iobase;
int s;
struct siocnstate sp;
+ speed_t speed;
- if (minor(dev) == siogdbunit)
+ if (minor(dev) == siogdbunit) {
iobase = siogdbiobase;
- else
+ speed = gdbdefaultrate;
+ } else {
iobase = siocniobase;
+ speed = comdefaultrate;
+ }
s = spltty();
- siocnopen(sp, iobase, comdefaultrate);
+ siocnopen(sp, iobase, speed);
if (inb(iobase + com_lsr) LSR_RXRDY)
c = inb(iobase + com_data);
else
@@ -3151,13 +3179,17 @@
Port_t iobase;
int s;
struct siocnstate sp;
+ speed_t speed;
- if (minor(dev) == siogdbunit)
+ if (minor(dev) == siogdbunit) {
iobase = siogdbiobase;
- else
+ speed = gdbdefaultrate;
+ } else {
iobase = siocniobase;
+ speed = comdefaultrate;
+ }
s = spltty();
- siocnopen(sp, iobase, comdefaultrate);
+ siocnopen(sp, iobase, speed);
while (!(inb(iobase + com_lsr) LSR_RXRDY))
Re: Logitech iFeel Optical USB Mouse cannot be attached.
This looks like an electrical problem. What happens if you connect the mouse directly to the machine, without any hubs? Nick On Sun, 23 Dec 2001, Raman Ng wrote: Hello all, I have already sent a mail about this problem before. I am a newbie of FreeBSD. This time I attached the dmesg output and kernel configuration for you all. I am using Asus A7V mb, Athlon 1.1 GHz CPU, 512 Mb RAM. Whenever the kernel boot up, the message device_probe_and_attach: ums0 attach returned 6. Details can refer to the attached detail.. This problem is similar to PR misc/30373 and there is no one handle it at all. I have tried FreeBSD 4.4-RELEASE, 4.5-PRERELEASE and 5.0-CURRENT (which is cvsup a month ago) and the problem is still persisted. I can use this mouse without any problem with Windows and Linux. Please give me any clue if I can solve this problem. Thanks in advance. Regards, Raman --- dmesg output --- Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.5-PRERELEASE #0: Sun Dec 23 01:55:47 HKT 2001 root@:/usr/obj/usr/src/sys/STABLE_DEBUG Timecounter i8254 frequency 1193182 Hz CPU: AMD Athlon(tm) Processor (1109.89-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x642 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc044b18,AMIE,DSP,3DNow! real memory = 536788992 (524208K bytes) avail memory = 518246400 (506100K bytes) Preloaded elf kernel kernel at 0xc0389000. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 9 entries at 0xc00f1750 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: VIA 8363 (Apollo KT133) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: NVidia model 0110 graphics accelerator at 0.0 irq 11 isab0: VIA 82C686 PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686 ATA66 controller port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: VIA 83C572 USB controller port 0xd400-0xd41f irq 9 at device 4.2 on pci0 uhci0: LegSup = 0x003b uhci_run: setting run=0 uhci_run: done cmd=0x80 sts=0x20 uhci_run: setting run=1 uhci_run: done cmd=0x81 sts=0x0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xd000-0xd01f irq 9 at device 4.3 on pci0 uhci1: LegSup = 0x0010 uhci_run: setting run=0 uhci_run: done cmd=0x80 sts=0x20 uhci_run: setting run=1 uhci_run: done cmd=0x81 sts=0x0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci_device_request: not done, ii=0xc104f680 uhub2: ALCOR Generic USB Hub, class 9/0, rev 1.10/1.00, addr 2 uhub2: 4 ports with 4 removable, self powered uhci_device_intr_transfer: not done, ii=0xc104f620 uhci_waitintr: timeout uhci_idone: error, addr=3, endpt=0x00, status 0x50BABBLE,STALLED uhci_waitintr: timeout usbd_transfer_cb: short transfer 01 uhci_waitintr: timeout usbd_transfer_cb: short transfer 01 ums0: Logitech, Inc. iFeel Mouse, rev 1.00/1.01, addr 3, iclass 3/1 uhci_waitintr: timeout usbd_transfer_cb: short transfer 074 device_probe_and_attach: ums0 attach returned 6 uhci_waitintr: timeout usbd_transfer_cb: short transfer 01 uhci_waitintr: timeout usbd_transfer_cb: short transfer 01 uhci_waitintr: timeout usbd_transfer_cb: short transfer 04 uhci_waitintr: timeout usbd_transfer_cb: short transfer 04 chip1: VIA 82C686 ACPI interface at device 4.4 on pci0 rl0: RealTek 8139 10/100BaseTX port 0xa400-0xa4ff mem 0xd580-0xd58000ff irq 9 at device 9.0 on pci0 rl0: Ethernet address: 00:50:ff:60:0b:b8 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcm0: Creative EMU10K1 port 0xa000-0xa01f irq 5 at device 10.0 on pci0 pci0: unknown card (vendor=0x104c, dev=0x8020) at 13.0 irq 9 atapci1: Promise ATA100 controller port 0x8000-0x803f,0x8400-0x8403,0x8800-0x8807,0x9000-0x9003,0x9400-0x9407 mem 0xd400-0xd401 irq 10 at device 17.0 on pci0 ata2: at 0x9400 on atapci1 ata3: at 0x8800 on atapci1 orm0: Option ROMs at iomem 0xc-0xcbfff,0xcc000-0xc,0xd-0xd27ff on isa0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0
Re: USB and -current
It would be trivial to write a driver, like uscanner, that does the collection of two endpoints into one bidirectional file descriptor. Endpoints are the pipes that USB communicates over, and due to sloppy documentation in the USB spec. implementors of firmware didn't realise that 1-in and 1-out are different endpoints. If 1-in and 1-out would have been used, ugen0.1 could have been used bidirectionally and all would have been well. Nick On Tue, 13 Nov 2001, Peter Wemm wrote: Julian Elischer wrote: I haven't been able to find the usb mailing list where's it gone? I've been trying ot run some USB programs specifically gphoto2 and I came to the conclusion that there may be some incompatibility in the libusb layer.. since then I discovered that there are TWO libusb's.. One from NetBSD and one from the world of pinguins (Actually sourcforge) It seems to me that our libusb needs to be called libusb-hid since it only supports the HID compatible devices and the one at sourceforge should probably be called libusb. Has anyone managed to get the libusb (gpl) to work under freeBSD -current? More specifically has anyone managed to get the gphoto2 library to work? Yes. There are fundamental differences between our usb kernel stack and gphoto's assumptions. I know of one person who has made it work, I think it was Daniel O'Connor (If I remember the name right). The biggest problem was that you have to open *two* fd's to the camera (one for send, one for recieve) vs. the single fd that serial and linux use. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: USB and SMP
Definitely the drivers. UHCI is a pile of that stuff that smells. Nick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Daniel O'Connor Sent: 11 November 2001 03:21 To: Jim Bryant Cc: [EMAIL PROTECTED]; Michael Class Subject: Re: USB and SMP On 10-Nov-2001 Jim Bryant wrote: I have a [secondary] USB Keyboard with a mouse port on it's side installed, as well as a cameramate CompactFlash reader hooked up. Both work. What chipset though? The OHCI stuff seems less reliable than UHCI. Not sure if its the hardware, the driver or some combination :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: WARNING: Driver mistake: destroy_dev on 154/0
Yes. I have no idea why phk has not done this. As this is a purposeful panicing of systems that worked fine before, I presume that someone is keeping track of the problems that are occurring and going to do something about it? Or is this a bad case of 'someone else's problem'? Nick On Tue, 30 Oct 2001, John Baldwin wrote: On 30-Oct-01 Poul-Henning Kamp wrote: In message 000801c1617c$9599ad00$[EMAIL PROTECTED], Jan Stocker writes: Ive updated the first time my system to current (Oct-28, with cvsup). After a make buildword and installworld, i made a new GENERIC kernel and copied the file GENERIC.hints to /boot/device.hints and installed the new kernel. I ve updated all files in /etc and remade all devices. Now a bootup hangs: a) The kernel is loading b) acpi.ko is loading c) Pentium Pro MTRR support enable d) WARNING: Driver mistake: destroy_dev on 154/0 next is a kernel panic dont do that Remove the asr driver from your kernel config until somebody fixes its use of destroy_dev() Maybe we should remove it from GENERIC? Warner, do you think we need an updating entry for this? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
FW: USB Multimedia Card (MMC) readers supported?
Try [EMAIL PROTECTED] for more information. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jim Bryant Sent: 20 September 2001 15:19 To: Konstantin Chuguev Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: USB Multimedia Card (MMC) readers supported? I believe at least one version of the SanDisk one is supported, and I recently helped test and get committed the Microtech CameraMate I personally recommend the CameraMate, as it has support for all known CompactFlash devices, including IBM Microdrives, as well as the fact that it also reads SmartMedia cards. Konstantin Chuguev wrote: Hello, Are USB MMC Card Readers (such as SanDisk ImageMate) supported in CURRENT? I suppose they can be treated as generic SCSI-over-USB drives, just want to be sure... Thanks, jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! - POWER TO THE PEOPLE! - Religious fundamentalism is the biggest threat to international security that exists today. United Nations Secretary General B.B.Ghali _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: top(1) takes ages to start up
Why don't you add an early-out for namelength = 15 or put the
if-statement in the loop:
Index: machine.c
===
RCS file: /home/ncvs/src/usr.bin/top/machine.c,v
retrieving revision 1.44
diff -u -r1.44 machine.c
--- machine.c 2001/05/31 22:36:51 1.44
+++ machine.c 2001/09/08 09:48:03
@@ -216,13 +216,16 @@
while ((pw = getpwent()) != NULL) {
if (strlen(pw-pw_name) namelength)
namelength = strlen(pw-pw_name);
+ if (smpmode namelength 13) {
+ namelength = 13;
+ break;
+ } else if (namelength 15) {
+ namelength = 15;
+ break;
+ }
}
if (namelength 8)
namelength = 8;
-if (smpmode namelength 13)
- namelength = 13;
-else if (namelength 15)
- namelength = 15;
if ((kd = kvm_open(/dev/null, /dev/null, /dev/null, O_RDONLY,
kvm_open)) == NULL)
return -1;
On Fri, 7 Sep 2001, Thomas Quinot wrote:
... because it walks through the entire NIS db just to find out what the
longest user name is (/src/usr.bin/top/machine.c 1.5). At this site,
this means 2800 RPC calls and dozens of seconds when the network and/or
NIS server are busy.
What do others think of the following patch?
Thomas.
--- machine.c.distFri Jun 1 00:36:51 2001
+++ machine.c Fri Sep 7 16:31:45 2001
@@ -212,7 +212,7 @@
sysctlbyname(kern.smp.active, smpmode, modelen, NULL, 0) 0) ||
modelen != sizeof(smpmode))
smpmode = 0;
-
+#ifndef NO_GETPWENT
while ((pw = getpwent()) != NULL) {
if (strlen(pw-pw_name) namelength)
namelength = strlen(pw-pw_name);
@@ -223,6 +223,9 @@
namelength = 13;
else if (namelength 15)
namelength = 15;
+#else
+namelength = 8;
+#endif
if ((kd = kvm_open(/dev/null, /dev/null, /dev/null, O_RDONLY,
kvm_open)) == NULL)
return -1;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Firewire driver available
I haven't looked at the OHCI spec for firewire at all, but it seems that
it was intended to be one specification. The OHCI spec puts a lot of
processing into the hands of the chip and the interaction is smart
enough to not require weird locking or delays (like the UHCI requires),
so it could be worthwhile to have a look whether we could integrate the
two.
Nick
Moved to current:
Is there any chance that the OHCI code inthe firewire driver and the OHCI
code in the USB drivers might be rationalised?
Both seem to talk with the CAM system (from quick reading) as well,
so it might seem that there is some common functionality.
BTW is the struct ahb_softc{} seems to suggest it's from the ahb driver
--
++ __ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ [EMAIL PROTECTED] +--x USA\ a very strange
| ( OZ)\___ ___ | country !
+- X_.---._/presently in San Francisco \_/ \\
v
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: kern/29530
Done. Will be MFC-ed after 4.4-RELEASE. On Thu, 23 Aug 2001, Eugene M. Kim wrote: Could anybody examine and commit the patch in the PR kern/29530? It fixes the support for KingByte USB Pen Drive by adding a quirk entry to src/sys/cam/scsi/scsi_da.c. It would be even better if this were MFC'ed before 4.4 comes out. Thank you in advance! Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: another panic (mix ppp and usb to taste)
What you are doing doesn't work for sure. You are piping in and out of
the control enpoint which won't work. Perhaps
/usr/sbin/ppp -quiet -direct -nat /dev/ugen0.1
would work, if there is an endpoint 1-in and an endpoint 1-out and they
are both related to data transfer. Normally this is not the case. See
the 3Com 5605 modem.
USB is NOT a serial protocol. It has nothing in common with a serial
port.
Nick
P.S.: The reason why it crashes is that it looks for an endpoint
descriptor for endpoint 0 which doesn't exist. i'll fix that.
On Fri, 24 Aug 2001, Mikhail Teterin wrote:
As I was trying to let the Palm Pilot connect to my desktop
through usb using PPP, I tried to run
/usr/sbin/ppp -quiet -direct -nat /dev/ugen0
While, perhaps, not the right way to do what I want (what is? aren't
serial devices the simplest?), it should not panic (nothing should
really). But it does, and quite repeatedly (some more comments after
the trace):
IdlePTD 4984832
initial pcb at 3db040
panicstr: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 0100
fault virtual address = 0x3
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01d5a0b
stack pointer = 0x10:0xce7f1c4c
frame pointer = 0x10:0xce7f1c58
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 442 (ppp)
trap number = 12
panic: page fault
cpuid = 0; lapic.id = 0100
boot() called on cpu#0
syncing disks... panic: bwrite: buffer is not busy???
cpuid = 0; lapic.id = 0100
boot() called on cpu#0
Uptime: 10m14s
dumping to dev da0b, offset 131200
dump ... 2 1 0
---
[...]
#12 0xc030b0bc in trap (frame={tf_fs = -1071644648, tf_es = -830734320,
tf_ds = 16777232, tf_edi = 64, tf_esi = 0, tf_ebp = -830530472,
tf_isp = -830530504, tf_ebx = -1049243648, tf_edx = -1049243428,
tf_ecx = 34, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1071818229, tf_cs = 8, tf_eflags = 66178,
tf_esp = -830530412, tf_ss = -1049288448})
at ../../../i386/i386/trap.c:405
#13 0xc01d5a0b in ugenpoll (dev=0xc1752100, events=64, p=0xce7abb80)
at ../../../dev/usb/ugen.c:1369
#14 0xc01ed604 in spec_poll (ap=0xce7f1c94)
at ../../../fs/specfs/spec_vnops.c:333
#15 0xc01ed27d in spec_vnoperate (ap=0xce7f1c94)
at ../../../fs/specfs/spec_vnops.c:119
#16 0xc0252333 in vn_poll (fp=0xc17328c0, events=64, cred=0xc1734700,
p=0xce7abb80) at vnode_if.h:381
#17 0xc0228b8b in selscan (p=0xce7abb80, ibits=0xce7f1d48,
obits=0xce7f1d3c, nfd=1) at ../../../sys/file.h:192
#18 0xc02286b5 in select (p=0xce7abb80, uap=0xce7f1f80)
at ../../../kern/sys_generic.c:772
#19 0xc030bf2d in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134842880, tf_esi = 134842880, tf_ebp = 0,
tf_isp = -830529580, tf_ebx = 3, tf_edx = 134996480,
tf_ecx = 134996352, tf_eax = 93, tf_trapno = 12, tf_err = 2,
tf_eip = 673178596, tf_cs = 31, tf_eflags = 643,
tf_esp = -1077937708, tf_ss = 47}) at ../../../i386/i386/trap.c:1129
(kgdb) up 13
#13 0xc01d5a0b in ugenpoll (dev=0xc1752100, events=64, p=0xce7abb80)
at ../../../dev/usb/ugen.c:1369
1369switch (sce-edesc-bmAttributes UE_XFERTYPE) {
(kgdb) p sce
$1 = (struct ugen_endpoint *) 0x0
(kgdb) l
1364printf(ugenpoll: no pipe\n);
1365return (EIO);
1366}
1367#endif
1368s = splusb();
1369switch (sce-edesc-bmAttributes UE_XFERTYPE) {
1370case UE_INTERRUPT:
1371if (events (POLLIN | POLLRDNORM)) {
1372if (sce-q.c_cc 0)
1373revents |= events (POLLIN | POLLRDNORM);
(kgdb) p events
$3 = 64
(kgdb) p s
No symbol s in current context.
(kgdb) p revents
$5 = 0
What I don't understand, is -- there is a check, just a few lines
above:
if (sce == NULL)
return (EINVAL);
How come it is not being caught there? Thanks,
--
|\__-__/|
_/ : :::\_
'__--( ..::)--__` -mi
If you have a / _- \/ :::\/ -_
serious knowledge/ / :. .\ \
about computers -- | | Ok, let's say you broke
keep it in a secret! _|/ ::\|_ the wall with your head
Rules of dating, / /:/:_::\::\:.\ What are you going to
'Playboy', ? 1994 | :| ..:(_/ \::|::|::| do in the next cell?
| :|:. ::|: |::|.:| Stanislaw J. Lec
\ |:: :::_/::/: :|:/
((___\\/___/___))
To Unsubscribe: send
Re: 5.0 Question
Hardly any USB CD are supported as they are mainly ATAPI based. Nick On Mon, 9 Jul 2001, Person, Roderick wrote: I was reading the 5.0 Release notes and Hardware text. The release notes mention that usb support was added to the generic kernel and the installation program to allow for support out of the box. The hardware notes make no mention of usb cd support(unless I missed it)? Is it there? Roderick P. Person Programmer II (412)454-2616 [EMAIL PROTECTED] Without censorship, things can get terribly confused in the public mind. - General William Westmoreland To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GENERIC kernel hangs at boot (uhci-related)
Could be, and I certainly don't know much about this code. But it seems like the driver is being given reason to assume it has a working device when it doesn't really have one. I assume the device is unusable without its interrupt, so shouldn't it fail at probe or attach time? Yes, it should. It's not bright enough to do that yet. 'It' in the second case refers to the PCI irq allocation code I presume? An irq that is 0 or 255 is invalid and should not be allocated to a PCI device. But speaking about rev1.32, how would you assign an interrupt as is stated in the log message for rev1.32? Nick To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Syscons mouse char range redefine proposal
You might want to specify in the comment what the arguments should look
like, like an example.
Nick
On Thu, 19 Apr 2001, Andrey A. Chernov wrote:
On Thu, Apr 19, 2001 at 21:23:57 +0900, Kazutaka YOKOTA wrote:
Maybe we should automatically add `-M 3' to flags for vidcontrol
in rc.conf for those languages...
Please review this patch:
--- defaults/rc.conf.old Tue Apr 10 05:34:17 2001
+++ defaults/rc.conf Thu Apr 19 16:46:40 2001
@@ -292,6 +292,8 @@
moused_type="auto" # See man page for rc.conf(5) for available settings.
moused_port="/dev/psm0" # Set to your mouse port.
moused_flags="" # Any additional flags to moused.
+mousechar_start="NO"# if 0xd0-0xd4 default range occuped in the font code
+ # table, specify alternative range start like 3
allscreens_flags="" # Set this vidcontrol mode for all virtual screens
--- rc.syscons.oldMon Jan 22 09:04:56 2001
+++ rc.sysconsThu Apr 19 16:45:12 2001
@@ -160,6 +160,13 @@
[Yy][Ee][Ss])
echo -n ' moused'
moused ${moused_flags} -p ${moused_port} -t ${moused_type}
+ case ${mousechar_start} in
+ [Nn][Oo] | '')
+ ;;
+ *)
+ echo -n ' mousechar_start'; vidcontrol ${viddev} -M
${mousechar_start}
+ ;;
+ esac
vidcontrol ${viddev} -m on
;;
esac
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
--
Qube Software, Ltd. Private:
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.qubesoft.com/ http://www.etla.net/~n_hibma/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: usb modems
The device SHOULD work, but I have not been able to test it. What kind of problems are you seeing? Nick On 30-Mar-01 Adrian Browne wrote: I was wondering if anyone has had any success with a usb isdn 3com modem or other usb modem types. I have a usb scanner and printer that works great on release 5.0-20010120, but i have failed miserably to get a usb/modem to work. Does anyone know? or could some one advise me of the best approach to a fix or a how2. I ve tried www.usb.org and well errmm no succes :( I recently bought a NetCOMM Roadster II which works very well.. (At least I can dial up and stuff - haven't exaustivly tested it) You may have a Win Modem :( --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildkernel failed
Sorry, me lame. I got distrcacted between committing usbdevs and its derivative usbdevs.h. I've committed the file and am doing a complete kernel build and will commit uscanner.c 1.8 again after that. Sorry. Nick On Thu, 4 Jan 2001, John Indra wrote: Dear all... Recent -CURRENT make buildkernel target died with this message: === uscanner cc -O -pipe -g -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -mpreferred-stack-boundary=2 -c /usr/src/sys/modules/uscanner/../../dev/usb/uscanner.c/usr/src/sys/modules/uscanner/../../dev/usb/uscanner.c:146: `USB_PRODUCT_EPSON_1640' undeclared here (not in a function) /usr/src/sys/modules/uscanner/../../dev/usb/uscanner.c:146: initializer element is not constant /usr/src/sys/modules/uscanner/../../dev/usb/uscanner.c:146: (near initialization for `scanner_ids[45].product') *** Error code 1 Stop in /usr/src/sys/modules/uscanner. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/DANTE. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. /john To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: state of usb?
Could you send me the output of dmesg and the complaints usbd is producing? Nick On Tue, 21 Nov 2000 [EMAIL PROTECTED] wrote: What is the current state of the usbd? I keep getting messages that complain about a host controller error and a shutdown of the usb interface. And I don't even have any devices on my usb ports... JAN To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB modem?
Whether a device is recognized by a driver depends on one thing only: the probe routine in the driver. It either has to conform to the specs and this device obviously doesn't, or it has to be supported by the driver and therefore the IDs of the device need to be known. The entries in usbdevs* are simply converted to a list of device names plus defines for the use of drivers, to make things simpler. Nick On Tue, 12 Dec 2000, Mark Huizer wrote: Is it a case of being in the usbdevs list _and_ supporting those specs? Or just following the specs? I believe that being listed in usbdevs isn't a requirement, but I'm not positive. I also haven't had any look getting the thing to work dynamically loading the various modules involved. It is detected as a generic device: ugen0: Siemens AG Vox Chicago 390 ISDN, rev 1.10/1.00, addr 2 I will try to build a kernel with the umodem device in it, see if that makes a difference -- Nice testing in little China... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HP ScanJet 5200C seems to be supported!
Daniel reported that the HP ScanJet 5200C USB scanner works with the uscanner driver. This means that most probably the following scanners now will work: HP ScanJet 4100C HP ScanJet 5200C HP ScanJet 6300C Note: This excludes the 4200C as it _is_ not compatible with the rest of them. Thanks to Daniel for pointing out a silly CutPaste error on my side. Please mail me any additional names of devices that work so I can add them to HARDWARE.TXT. Nick -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ -- Forwarded message -- Date: Wed, 01 Nov 2000 11:20:21 +1030 (CST) From: Daniel O'Connor [EMAIL PROTECTED] To: Nick Hibma [EMAIL PROTECTED] Cc: USB BSD list [EMAIL PROTECTED] Subject: Re: HP ScanJet 5200C On 01-Nov-00 Nick Hibma wrote: [sound of someone slapping forehead] Do'h! Cutpaste error when copying stuff from ugen. Here is the patch. Both committed to stable and current. Please let me know whether this makes your scanner work. It's much more talkative now.. :) :) OK, a preview scan worked great. *bounce* --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Driver Floppy implementation (Re: make release breakage -dokern.sh patch 2)
I'm not sure whether the problem of loading secondary usb modules is a problem in 4.x but it is easy to try. Boot a machine without usb support compiled in. after login, kldload usb, then the miibus and then the if_aue modules. If that works, you should be ok. I cannot test this as at the moment as I don't have a STABLE box (will have once the first RC comes out of JKH factories). Nick On Mon, 30 Oct 2000, Takanori Watanabe wrote: In message [EMAIL PROTECTED], Tatsumi Hosokawa $B$5$s$$$o$/(B: I moved PCI/PCCARD/USB if_xx.ko driver to mfsroot.flp, and I've got 100KB of free blocks in the first floppy. If we move more drivers to mfsroot.flp or coming drivers.flp, we can get not only free blocks in the first floppy, but also more installation devices. Just FYI: If usb itself is module-ifed, USB ether modules cannot be load until MODULE_DEPEND,MODULE_VERSION is defined. Takanori Watanabe a href="http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html" Public Key/a Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Support for USB scanners in FreeBSD
FreeBSD now has preliminary support for USB scanners. You will need to have SANE installed in order to use the uscanner driver. You can kldload the uscanner driver. Please do not contact me personally with questions on which scanner is supported. You can get this information from http://www.etla.net/~n_hibma/usb/uscanner-support.pl If you have questions or would like to notify us of additional scanners that work through the uscanner driver, please post them to the USB-BSD mailing list available from http://lists.inteltec.com/wws/info/usb-bsd Cheers, Nick -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Support for USB scanners in FreeBSD
Grmbl... Alan Clegg reported that the URL is not working. Not that there is much to see yet, but the correct URL should be: http://www.etla.net/~n_hibma/usb/uscanner-supported.pl Sorry about that. Nick FreeBSD now has preliminary support for USB scanners. You will need to have SANE installed in order to use the uscanner driver. You can kldload the uscanner driver. Please do not contact me personally with questions on which scanner is supported. You can get this information from http://www.etla.net/~n_hibma/usb/uscanner-support.pl If you have questions or would like to notify us of additional scanners that work through the uscanner driver, please post them to the USB-BSD mailing list available from http://lists.inteltec.com/wws/info/usb-bsd Cheers, Nick -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uscanner driver
Did you check on the SANE home page whether your scanner is supported? This is a USB driver and a trivial driver at that, with no vendor specific code. So I won't be able to help. Nick I've quickly thrown together a driver for USB scanners. Unforunately, I don't have a scanner available that is supported by SANE, so I can't test it. How about parallel scanners? I have a UMAX Astra 2000p PPT scanner. I've heard that UMAX didn't want to release the specs, because they've got a proprietary ASIC in there. If anyone's willing to discuss this matter on a different list, I'm willing to do so. -Donn -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
uscanner driver
I've quickly thrown together a driver for USB scanners. Unforunately, I
don't have a scanner available that is supported by SANE, so I can't
test it.
The driver is a rip-off of the ugen, with some bits of udbp thrown in
for good measure. It relies on a very recent version of usbdevs, so make
sure your system is up to date.
I'd appreciate it if someone that has a supported scanner (see
http://www.mostang.com/sane/sane-backends.html
) would pick this driver up and turn it into something that works. If
your scanner is supported by SANE, but not recognised by uscanner.ko,
add the id for your scanner (usbdevs -v) to usbdevs and uscanner.h and
recompile and try again.
To install it:
Install Gimp
Install Sane
Copy uscanner.c .h (attached) to /sys/dev/usb
Mkdir /sys/modules/uscanner
Copy Makefile (attached) to /sys/modules/uscanner/
patch your kernel with the file uscanner.patch (attached)
cd /sys/
patch /tmp/uscanner.patch
And compile load the thing
cd /sys/modules/uscanner
make load
Be warned! This driver will reboot your machine, break it, send your dog
on a holiday and will turn the weather into hail for the next three
weeks. If any of that does not happen, you just got lucky, don't have a
dog or live in Scotland.
Let me know!
Nick
--
Qube Software, Ltd. Private:
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.qubesoft.com/ http://www.etla.net/~n_hibma/
/* $FreeBSD$ */
/*
* Copyright (c) 1998 The NetBSD Foundation, Inc.
* All rights reserved.
*
* This code is derived from software contributed to The NetBSD Foundation
* by Lennart Augustsson ([EMAIL PROTECTED]) at
* Carlstedt Research Technology.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
*must display the following acknowledgement:
*This product includes software developed by the NetBSD
*Foundation, Inc. and its contributors.
* 4. Neither the name of The NetBSD Foundation nor the names of its
*contributors may be used to endorse or promote products derived
*from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
* ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
* TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
#include sys/param.h
#include sys/systm.h
#include sys/kernel.h
#include sys/malloc.h
#if defined(__NetBSD__) || defined(__OpenBSD__)
#include sys/device.h
#elif defined(__FreeBSD__)
#include sys/module.h
#include sys/bus.h
#include sys/conf.h
#include sys/fcntl.h
#include sys/filio.h
#endif
#include sys/tty.h
#include sys/file.h
#include sys/select.h
#include sys/proc.h
#include sys/vnode.h
#include sys/poll.h
#include dev/usb/usb.h
#include dev/usb/usbdi.h
#include dev/usb/usbdi_util.h
#include dev/usb/usbdevs.h
#include dev/usb/uscanner.h
#ifdef USCANNER_DEBUG
#define DPRINTF(x) if (uscannerdebug) logprintf x
#define DPRINTFN(n,x) if (uscannerdebug(n)) logprintf x
int uscannerdebug = 10;
#else
#define DPRINTF(x)
#define DPRINTFN(n,x)
#endif
#define USCANNER_BUFFERSIZE 1024
struct uscanner_softc {
USBBASEDEVICE sc_dev; /* base device */
usbd_device_handle sc_udev;
usbd_interface_handle sc_iface;
usbd_pipe_handlesc_bulkin_pipe;
int sc_bulkin;
usbd_xfer_handlesc_bulkin_xfer;
void*sc_bulkin_buffer;
int sc_bulkin_bufferlen;
int sc_bulkin_datalen;
Re: Will the urio dev make it to -stable?
Due to lack of time and other priorities I've not had a good look at the driver for problems. I think that the initial submitter has a more recent version available and that one should be tested. The NetBSD version is also different and I need to look at what that one does. Also, a patch to the UHCI driver is needed to get performance up to reasonable levels (bandwidth reclamation). Nick On Sun, 16 Jul 2000, Frank Mayhar wrote: ...any time soon? It's been in current since 3/16 so it would seem MFCable, but what do I know. Nick? (I run 4-stable and don't plan to run -current any time soon, _and_ I want to buy a Rio 500, but not if I can't hook it to FreeBSD.) Sent to both -current and -stable as both lists seem relevant. Please limit followups, though. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://store.exit.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic: lockmgr: pid 5, not exclusive lock holder 0 unlocking
The word is that there is a problem but it is a software problem. For some reason the virtual hub gives an IOERROR, but I haven't had the time or seen the need to figure that one out. It seems to be harmless though. nick And what is the word on thise IOERROR's given by my kernel when its init'ing its usb stack. uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub0: port 1 power on failed, IOERROR uhub0: port 2 power on failed, IOERROR ? -Steve -- Stephan van Beerschoten[EMAIL PROTECTED] PGP fingerprint: 4557 9761 B212 FB4C 778D 3529 C42A 2D27 "This email was brought to you by your local pop server" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic in xpt_setup_ccb (cam_xpt.c)
Hm, I had a look at the source code, and to be honest I can't find a
single reason why the path would be unset.
Did the CD reader detached itself from the bus in the meantime, or did
something like a bus error occur? Check your messages log around the
time the panic occurred to see if something like that happened.
At that point in the code it was using the path variable stored in the
periph and that one is available from when the peripheral was allocated
up to the point where the refcount for the peripheral reaches zero (that
could be wrong) or the device is invalidated.
Nick
On Sat, 29 Jul 2000, Alexander Leidinger wrote:
Hi,
while trying to read (dd if=/dev/cd0c) from a damaged cd (the surface is
a little bit damaged), I've got a panic:
---snip---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:303
#1 0xc01a0f19 in panic (fmt=0xc029aa60 "lockmgr: pid %d, not %s %d unlocking")
at ../../kern/kern_shutdown.c:553
#2 0xc019b194 in lockmgr (lkp=0xc14f4a00, flags=65542, interlkp=0xd0e2e22c,
p=0xd0313ba0) at ../../kern/kern_lock.c:382
#3 0xc01cf2af in vop_stdunlock (ap=0xd0d2ecc8) at ../../kern/vfs_default.c:255
#4 0xc022b641 in ufs_vnoperate (ap=0xd0d2ecc8)
at ../../ufs/ufs/ufs_vnops.c:2301
#5 0xc01d22aa in vput (vp=0xd0e2e1c0) at vnode_if.h:794
#6 0xc0222ea7 in ffs_sync (mp=0xc1046a00, waitfor=2, cred=0xc0b3f980,
p=0xc037f0a0) at ../../ufs/ffs/ffs_vfsops.c:955
#7 0xc01d4295 in sync (p=0xc037f0a0, uap=0x0) at ../../kern/vfs_syscalls.c:551
#8 0xc01a094f in boot (howto=256) at ../../kern/kern_shutdown.c:225
#9 0xc01a0f19 in panic (fmt=0xc02babef "page fault")
at ../../kern/kern_shutdown.c:553
#10 0xc0265846 in trap_fatal (frame=0xd0d2ee10, eva=68)
at ../../i386/i386/trap.c:929
#11 0xc02654f9 in trap_pfault (frame=0xd0d2ee10, usermode=0, eva=68)
at ../../i386/i386/trap.c:822
#12 0xc02650bf in trap (frame={tf_fs = 16, tf_es = -791543792,
tf_ds = -1072562160, tf_edi = 1, tf_esi = -1056803840,
tf_ebp = -791482800, tf_isp = -791482820, tf_ebx = 0, tf_edx = 64,
tf_ecx = -791482776, tf_eax = 1, tf_trapno = 12, tf_err = 0,
tf_eip = -1072541595, tf_cs = 8, tf_eflags = 2163330,
tf_esp = -791482664, tf_ss = -107284}) at ../../i386/i386/trap.c:427
#13 0xc0125065 in xpt_setup_ccb (ccb_h=0xd0d2ee68, path=0x40, priority=1)
at ../../cam/cam_xpt.c:3734
#14 0xc01219c0 in cam_release_devq (path=0x40, relsim_flags=0, openings=0,
timeout=0, getcount_only=0) at ../../cam/cam_periph.c:855
---Type return to continue, or q return to quit---
#15 0xc0121b37 in camperiphdone (periph=0xc1021480, done_ccb=0xc1027400)
at ../../cam/cam_periph.c:1021
#16 0xc0127997 in camisr (queue=0xc03189b0) at ../../cam/cam_xpt.c:6328
#17 0xc01277a9 in swi_cambio () at ../../cam/cam_xpt.c:6231
#18 0xc025b900 in splz_swi ()
#19 0xc01a7451 in softclock () at ../../kern/kern_timeout.c:131
#20 0xc025b85f in doreti_swi ()
Cannot access memory at address 0x91992874.
(kgdb) up 13
#13 0xc0125065 in xpt_setup_ccb (ccb_h=0xd0d2ee68, path=0x40, priority=1)
at ../../cam/cam_xpt.c:3734
3734ccb_h-path = path;
(kgdb)
(kgdb) print path
$1 = (struct cam_path *) 0x0
(kgdb) print ccb_h
$2 = (struct ccb_hdr *) 0x0
(kgdb) up
#14 0xc01219c0 in cam_release_devq (path=0x40, relsim_flags=0, openings=0,
timeout=0, getcount_only=0) at ../../cam/cam_periph.c:855
855 xpt_setup_ccb(crs.ccb_h, path,
(kgdb) print path
$5 = (struct cam_path *) 0x40
(kgdb) print *path
Cannot access memory at address 0x40.
---snip---
It's a kernel from yesterday.
Bye,
Alexander.
--
If Bill Gates had a dime for every time a Windows box crashed...
...Oh, wait a minute, he already does.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] USB project
http://www.etla.net/~n_hibma/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
WARNING: IBM microdrive in USB based CF II reader
Warning: Do not use IBM Microdrives in any USB based CF II readers, like the SmartMedia ImageMate until further notice. I've had reports of 2 drives breaking in a SmartMedia ImageMedia. They are PHYSICALLY broken and will no longer work. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cvs commit: src/sys/dev/ppbus ppb_base.c (fwd)
Could people try this out and see whether this solves any problems with detection of Zip drives? You might have to add flags=0x01 to ppc to use NIBBLE mode. If enough people respond I'll try and get this into 4.1-RC. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ -- Forwarded message -- Date: Tue, 18 Jul 2000 13:16:16 -0700 (PDT) From: Nick Hibma [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/sys/dev/ppbus ppb_base.c n_hibma 2000/07/18 13:16:16 PDT Modified files: sys/dev/ppbusppb_base.c Log: Fix the detection of parallel port Zip drives. Submitted by: j mckitrick [EMAIL PROTECTED] Reviewed by: nsouchu Revision ChangesPath 1.11 +6 -5 src/sys/dev/ppbus/ppb_base.c To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB modems
Right, I finally committed the driver you sent me. let me know if I've made a mistake and committed the wrong one. Mike, which Supra modem do you have? I've got a SupraMax 56K modem, SUP2920 and it gives me a rainforest worth of endpoints, not somethig that looks like a ACM CD Class device. Nick On Wed, 28 Jun 2000, Mike Meyer wrote: Warner Losh writes: In message l03130304b57ec3bf8693@[194.32.164.2] Bob Bishop writes: : Can anyone give a quick synopsis of the current status of support for USB : modems? TIA They aren't supported yet. There's at least one group that might be working on them. The value of supporting them is well known. Take care in your purcahse of a usb modem because some of them expect an isochronous audio stream... Nick (and I, for that matter) have a umodem.c that works, for some definition of "works". It seems to work fine on USR USB modems. On the Supra I bought (because it was easily available), it works for dialout and makes PPP connections, but outgoing IP connections fail under an indeterminate set of conditions. It's not clear where the problem is - I'll be investigating it as soon as I once again have free time (a couple of weeks). Nick has indicated he was going to try this version and commit it, but it hasn't happened yet. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB modems
Well, the one you committed doesn't have the notification support I added, or the serial state bits that are in usbcdc.h. Do you need/want copies of the one I've been working on? Yes, please. I must have them somewhere, but it might be a better idea to get your latest version. Looks like umodem.c didn't make it into conf/files, either. Fixed (NOTES as well). Man pages, we will need those as well. Anyone? Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: about Kern/15436
Could people, when posting these kinds of requests, add a one sentence outline of what the PR / web page contains? Most people do not take the time to look at the page if there is no barebones description of what the information contains. Thanks in advance. Nick P.S.: Keep posting them. It is one of the best ways to get people interested in the larger PRs and change requests. On Wed, 5 Jul 2000, Michael C. Wu wrote: Will you consider looking at : http://dorifer.heim3.tu-clausthal.de/~olli/propellers/ http://www.freebsd.org/cgi/query-pr.cgi?pr=15436 It is an additional functionality and should not pose a stability/tradition/POLA issue. Perhaps we can get this done in time for for 4.1-R? Regards, -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_de as a module...
The opt_ files can be generated by the makefiles, so there is no reason to remove those, see sys/modules/usb/Makefile SRCS = bus_if.h device_if.h usb_if.h usb_if.c \ vnode_if.h \ opt_usb.h \ ... Any file called opt_*.h that is not present is created (empty). Nick *I'll* check it too- I'd *love* to have if_de as a loadable since most of the alphas I have use if_de (not dc)! On Mon, 10 Jul 2000, Mark Murray wrote: Hi Bill If I apply the enclosed patch to sys/pci/if_de.c, and make a copy of (say) sys/modules/dc to sys/modules/de (while changing all relevant dc -- de), I can build a loadable module for de. Could you please check that this works in your (no doubt) excellent laboratory and either commit or review for me to commit. Thanks! :-) M Index: sys/pci/if_de.c === RCS file: /home/ncvs/src/sys/pci/if_de.c,v retrieving revision 1.129 diff -u -d -r1.129 if_de.c --- sys/pci/if_de.c2000/05/28 16:06:56 1.129 +++ sys/pci/if_de.c 2000/07/09 08:27:09 @@ -54,10 +54,9 @@ #include sys/bus.h #include sys/rman.h -#include "opt_inet.h" -#include "opt_ipx.h" - #include net/if.h +#include net/if_arp.h +#include net/ethernet.h #include net/if_media.h #include net/if_dl.h #ifdef TULIP_USE_SOFTINTR To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: _DIAGASSERT in libusb libutil
Fixed. Sorry. On Thu, 6 Jul 2000, John Baldwin wrote: Charles Anderson wrote: # grep -r DIAGASSERT . (from /usr/src) ./lib/libutil/fparseln.c: _DIAGASSERT(sp != NULL); ./lib/libutil/fparseln.c: _DIAGASSERT(p != NULL); ./lib/libutil/fparseln.c: _DIAGASSERT(fp != NULL); ./lib/libusb/data.c:_DIAGASSERT(p != NULL); ./lib/libusb/data.c:_DIAGASSERT(h != NULL); ./lib/libusb/data.c:_DIAGASSERT(p != NULL); ./lib/libusb/data.c:_DIAGASSERT(h != NULL); ./lib/libusb/descr.c: _DIAGASSERT(fd != -1); ./lib/libusb/parse.c: _DIAGASSERT(c != NULL); ./lib/libusb/parse.c: _DIAGASSERT(d != NULL); ./lib/libusb/parse.c: _DIAGASSERT(s != NULL); ./lib/libusb/parse.c: _DIAGASSERT(s != NULL); ./lib/libusb/parse.c: _DIAGASSERT(h != NULL); ./lib/libusb/parse.c: _DIAGASSERT(r != NULL); ./lib/libusb/parse.c: _DIAGASSERT(desc != NULL); ./lib/libusb/parse.c: _DIAGASSERT(h != NULL); ./make.out.070600.1528:/usr/obj/usr/src/i386/usr/lib/libusb.so: undefined reference to `_DIAGASSERT' Where does _DIAGASSERT come from? I updated right before I built which was 3:30 edt It's a macro that NetBSD uses just to be different from the rest of the known world which uses the assert() macro from /usr/include/assert.h. In libutil/fparseln.c, all the _DIAGASSERT() macro calls are #if 0/#endif'd out. A similar patch should fix libusb. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] buildworld broken in libusb
Yes, that will work. Sorry for breaking the build. The problem was some
stale files in my directories.
Nick
On Wed, 5 Jul 2000, Ollivier Robert wrote:
According to Ollivier Robert:
buildworld is broken in libusb. Here is a tentative patch (I'm re-building
the world right now). The alternative is to #define UPACKED in usbhid.h.
Forget that fix, it doesn't work.
This one will although I don't like it.
cvs diff: Diffing .
Index: usbhid.h
===
RCS file: /home/ncvs/src/sys/dev/usb/usbhid.h,v
retrieving revision 1.9
diff -u -2 -r1.9 usbhid.h
--- usbhid.h 2000/07/05 08:11:43 1.9
+++ usbhid.h 2000/07/05 11:14:13
@@ -55,4 +55,6 @@
#define UR_SET_PROTOCOL 0x0b
+#define UPACKED __attribute__ ((packed))
+
typedef struct usb_hid_descriptor {
uByte bLength;
--
Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- [EMAIL PROTECTED]
The Postman hits! The Postman hits! You have new mail.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] USB project
http://www.etla.net/~n_hibma/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: KAME integration and plans
Could you mention the locations (as in a set of paths) that are hands-off? I'll generate a list and put it somewhere (in the tree?) Good idea. To be honest, I was more thinking of the heads up message. But it was suggested to add it to the readme in netinet6/ Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KAME integration and plans
Could you mention the locations (as in a set of paths) that are hands-off? Nick On Wed, 5 Jul 2000, Kris Kennaway wrote: As itojun has already posted, we are in the process of updating the KAME IPv6/IPSEC code in FreeBSD to the latest KAME sources. In importing the latest KAME code, we are not being too concerned about whitespace or cosmetic diffs, unifdef'ing __NetBSD__ sections (at least in userland) and so forth. The reason for this is that KAME is externally maintained code, and so cosmetic differences in FreeBSD needlessly complicate the diffs and really make life harder for merging. The KAME team already have a difficult enough job in maintaining and developing the code on 11 different BSD releases without us making life more difficult for them by committing unneccessary code changes to FreeBSD. In this vein, I'd like to suggest a new "hands-off" policy of not committing gratuitous changes to KAME-derived code, including manpage changes, unless: a) The commit is required for operation on FreeBSD (in which case it's not really gratuitous) b) The commit is suitable for the other platforms KAME supports as well, and is submitted back to KAME to be merged into their master repo. If there are legitimate concerns with KAME code the place to get them fixed is upstream, not in FreeBSD. For example, the "hard sentence break" manpage sweeps should have been submitted back to KAME, and the "remove unneeded #includes" should not have touched the KAME code at all since it creates gratuitous diffs for no functional change. X years down the line if the KAME project disbands, we can do the FreeBSD style cleanups then. At the moment I am not bothering to merge in gratuitous FreeBSD changes to things like manpages, because we want to get this code into -current and tested as quickly as possible. Sheldon Hearn will be taking care of passing the manpage diffs back to KAME. I intend to MFC this stuff in 4 or 5 days assuming it doesn't present any problems, so this means we need everyone who is capable of doing so to stress the new code as much as possible. IMO we *really* need to get this into 4.1 despite the relatively short testing cycle, for the simple reason that the newer code is much more functional, and in particular supports the racoon IKE daemon for automatic management of IPSEFC security associations (i.e. manually-keyed SAs are no longer required) - this is already in ports. This is important for interoperability with other IPSEC implementations. I also would quite like to see ALTQ brought in - I have had lots of support for this and so far no objections - although I forgot to ask itojun not to unifdef that code before it was committed :-(. Perhaps if he has time he'll commit that as well. Userland binaries are not yet fully committed: the older binaries may not work corectly with the new kernel code. Anyone wanting to play with this stuff to help test it should check out www.freenet6.net, who provide a very simple way to establish a tunnel to the 6bone. Documentation is available on www.kame.net and related links. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: coldsync - Visor kernel panic / bug #17961
Nothing has happened so far. I have a handspring now, but lack the time currently to fix it. I'll have a go at it tomorrow if there is some time left. Nick On Tue, 27 Jun 2000, Sascha Lucky Luck wrote: Hi all, what is the story with this bug? (If you want a hand with testing patches, etc., please drop me a mail) I'm running 5.0-CURRENT (Jun 20) Hardware: Jun 26 15:34:28 bofh /kernel: usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 Jun 26 15:34:28 bofh /kernel: usb0: USB revision 1.0 Jun 26 15:34:28 bofh /kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1. 00, addr 1 Jun 26 15:34:28 bofh /kernel: uhub0: 2 ports with 2 removable, self powered Jun 26 15:34:28 bofh /kernel: uhub1: vendor 0x0698 product 0x, class 9/1, re v 1.00/0.01, addr 2 Jun 26 15:34:28 bofh /kernel: uhub1: 5 ports with 4 removable, self powered Jun 26 15:34:28 bofh /kernel: uhid0: vendor 0x0698 product 0x1786, rev 1.00/0.01 , addr 3, iclass 3/0 and the Visor: Jun 26 17:13:43 bofh /kernel: ugen0: Handspring Inc Handspring Visor, rev 1.00/1.00, addr 4 Thanks in advance, s. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: irunning, width in bits.
From what I understood from dfr, when switching away from an interrupt handler it is converted into a full thread. When the second piece of hardware fires an interrupt it could then run at the same time. I thought of this almost immediately - it's a bad idea though because it makes it hard to determine when to EOI an interrupt. If you expect to perform significant processing in your interrupt handler, you should consider a taskq. Right. It would be nice however to not have to go through the trouble of moving things onto different interrupts. Current BIOS's do not quite let you decide on which interrupt you would like to have assigned to the various cards. It will spread them in some way, but that might not spread the two high interrupt count cards onto separate interrupts. You have to move the hardware around in the slots to get things sorted in some cases. I guess that the perfect solution is to be able to hardwire the PCI irqs in some way once FreeBSD is doing the PnP resource allocation. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Unknown Devices
: usb tty and modems aren't supported, as far as I know. : : They're "nearly" there, AFAIR. I sent Nick some code a while back that : addressed the last problem I understood he had. I'll have to ask him about it then. Picked it up, looked at it, got distracted by Reality and must have dropped it again. I wish Reality would just back off for a while... Yes, the driver is here and it seems to work according to Mike Meyer (IIRC), he's fixed up a few other bits and pieces and I am ready to commit it, but I haven't had time to test it yet. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Unknown Devices
: Watch out - some USB modems are also WinModems. Not WinModems as such (the USB link is too slow to feed the DSP, but they do have proprietary protocols). 3COM modems are safe though. They are class compliant. Nick usb tty and modems aren't supported, as far as I know. How can you tell the usb modems that are win modems? And can y ou get docs on them? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hardware" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
irunning, width in bits.
What about shared interrupts? How are they going to be treated? With the spl leaving the arena it somehow looks feasible to run one interrupt source on two different threads if there are two pieces of hardware attached to the same interrupt line. From what I understood from dfr, when switching away from an interrupt handler it is converted into a full thread. When the second piece of hardware fires an interrupt it could then run at the same time. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
More over, unlike other big project like CAM, this baby is going to touch the gut of the OS. It might be possible however for individual projects to move into a separate branch. Nick What about doing the changes on a branch with the understanding that the branch will *replace* HEAD when it stabilises ? "CVS branches suck" is the reason I belive. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
CAM is not a valid example. It only touched the disk subsystem. Merging back changes in blocks might not be possible. As Matthew mentioned, Chuck's experience should be taken for a fact. And bounding the amount of breakage is almost impossible without squeezing the people doing the SMP work really badly. I don't think that that is reasonable. Nick One could argue that you could merge the changes to FreeBSD 5.X on a daily or weekly basis to that branch so that the branch doesn't get too far out of what. Perforce users do this all the time (cf the cam project). The model that I see is that a branch is created for SMP work, and that you find a volunteer who has access to SMP machines who will merge from current into the SMP branch once a week and boot the resulting kernel. If it works, he commits it, otherwise he resovles the problems. That way the main developers aren't significantly impacted by the merging. I'd be a lot happier if there was an upper bound on the length of time that -current would be unstable, if there was a plan in place on what to do if that timelimit was exceeded, if there was a roadmap I could look at, etc. Right now the vagueness of it all pushes my panic button. I'm trying to get more information so that I know if I should just calm down and it won't be that bad, or if I should pitch a huge fit because it will be too painful to make progress on any other front. Please help me with that. I'd also be happy if I could create a newcard branch off the last stable version of freebsd 5.0-current. That way I could continue my work with others and the instability wouldn't matter. All merging, if any, would be my responsibility. I don't know what the level of pain Of course the same arugment about merging you make could be made for new kernel work. They will either have to live with the pain (which is currently ill-defined at best, knowing what the pain would be would help my confort level), or do their work and then redo it on the new and improved FreeBSD months later. Why should SMP force others to do that? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
Although I would not like to put it as strongly as Warner does, I would like to ask how the decision makers expect the rest of the project to progress (the other 30 or so kernel committers) in a reasonable, not too time consuming way. Will there be a general mechanism for making patchsets against CURRENT-26-JUNE-2000 available? Will there be moments in time were the tree will be made and kept stable for a week or so for people to insert their fixes. What about xtra tags being laid at certain moments in time? Any schedule for that? Will all the spls in all the drivers be removed and replaced by other mechanisms by the SMP group in the process? This would create a lot of extra work if the code is shared between different source trees, for example between the *BSDs, if the spls/shims will be removed completely. On the side, I would like to suggest that some sort of posting of updates (by you, Jason?) is done on a regular basis (bi-weekly or so) to show progress and to indicate the state of important aspects of the kernel (VM, kernel threads, API's, etc.), so other people have an indication of how reliable the system is and when it would be a reasonable point in time for them to start working their code/fixes back into the tree again. I must say that I find it slightly annoying that this aspect is completely ignored in your initial e-mail and definitely would like to see this addressed properly before any tag goes down and breakage occurs. I can see that everybody is very excited about what is going to happen, but I would like to make sure the rest of us, who will only participate on the side, are not left in the cold for 2 months or so while the basic stuff is being done. In any case, thanks for the work you guys are doing. From what Doug told me there is a lot of really, really cool stuff coming our way. Nick On Tue, 20 Jun 2000, Warner Losh wrote: In message [EMAIL PROTECTED] Jason Evans writes: : Summary: -current will be destabilized for an extended period (on the order : of months). A tag (not a branch) will be laid down before the initial : checkin, and non-developers should either stick closely to that tag until : the kernel stabilizes, or expect large doses of pain. This tag will be : laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning : beforehand. Thanks for the fair warning. Now don't do it. Has core approved this? I don't think so, I've seen nothign from them about it. The instability ni -current for MONTHS is pain not acceptible. We've never really allowed that in the past. A CVS branch would be mcuh better for this sort of thing. I know that's a pain as well, but this is just for SMP people and the rest of us shouldn't have to deal with the pain. I understand your desire to have it all in a working tree, but causing pain for ALL developers for potentially MONTHS isn't a reasonable request. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Using KLD's with modules that depend other modules in the same file
When loading modules with other modules in the same linker file,
depending on each other, currently the kernel linker chokes. Example:
the uhub, uhci, ohci and usb modules are (for unrelated reasons) linked
into one big file. It is however impossible currently to preload that
file because the dependencies are not found if MODULE_DEPEND and
MODULE_VERSION are added in appropriate places.
Currently we do the following:
for all linker files
(A) check dependencies for all modules in linker file
against found_modules
if resolves
(B) add the modules to found_modules
The attached patch changes this to
for all linker files
(B) create a list of modules in the file (file_modules)
(A) check dependencies for all modules in linker file
against found_modules and file_modules
if resolves
(C) concatenate file_modules to found_modules
Step A and B are reversed and a copy loop (C) has been added.
As a side effect it is now also possible for modules to depend on
themselves (usb_depend_on_usb):
% nm /modules/usb.ko | grep depend_on
00019bc0 d _uhub_depend_on_usb
00019e88 d _usb_depend_on_usb
Comments?
Nick
P.S.: I am aware of the people involved being at Usenix, so I'll
postpone committing this until they have had time to comment on it.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] USB project
http://www.etla.net/~n_hibma/
Index: kern_linker.c
===
RCS file: /home/ncvs/src/sys/kern/kern_linker.c,v
retrieving revision 1.46
diff -w -u -r1.46 kern_linker.c
--- kern_linker.c 2000/05/26 02:04:34 1.46
+++ kern_linker.c 2000/06/19 23:36:24
@@ -923,11 +923,11 @@
*/
static modlist_t
-modlist_lookup(const char *name)
+modlist_lookup(modlisthead_t *modules, const char *name)
{
modlist_t mod;
-for (mod = TAILQ_FIRST(found_modules); mod; mod = TAILQ_NEXT(mod, link)) {
+for (mod = TAILQ_FIRST(modules); mod; mod = TAILQ_NEXT(mod, link)) {
if (!strcmp(mod-name, name))
return mod;
}
@@ -960,10 +960,12 @@
inti;
intresolves;
modlist_t mod;
+modlisthead_t file_modules;
TAILQ_INIT(loaded_files);
TAILQ_INIT(depended_files);
TAILQ_INIT(found_modules);
+TAILQ_INIT(file_modules);
error = 0;
modptr = NULL;
@@ -1002,7 +1004,7 @@
if (mp-md_type != MDT_VERSION)
continue;
modname = mp-md_cval;
- if (modlist_lookup(modname) != NULL) {
+ if (modlist_lookup(found_modules, modname) != NULL) {
printf("module %s already present!\n", modname);
/* XXX what can we do? this is a build error. :-( */
continue;
@@ -1025,34 +1027,20 @@
for (lf = TAILQ_FIRST(loaded_files); lf; lf = TAILQ_NEXT(lf, loaded)) {
deps = (struct linker_set*)
linker_file_lookup_symbol(lf, MDT_SETNAME, 0);
- /*
-* First, look to see if we would successfully link with this stuff.
-*/
+
resolves = 1; /* unless we know otherwise */
+
if (deps) {
- for (i = 0; i deps-ls_length; i++) {
- mp = linker_reloc_ptr(lf, deps-ls_items[i]);
- if (mp-md_type != MDT_DEPEND)
- continue;
- modname = linker_reloc_ptr(lf, mp-md_cval);
- if (modlist_lookup(modname) == NULL) {
- /* ok, the module isn't here yet, we are not finished */
- resolves = 0;
- }
- }
- }
/*
-* OK, if we found our modules, we can link. So, "provide" the
-* modules inside and add it to the end of the link order list.
+* First, find all the modules that are contained in the file.
*/
- if (resolves) {
- if (deps) {
for (i = 0; i deps-ls_length; i++) {
mp = linker_reloc_ptr(lf, deps-ls_items[i]);
if (mp-md_type != MDT_VERSION)
continue;
modname = linker_reloc_ptr(lf, mp-md_cval);
- if (modlist_lookup(modname) != NULL) {
+ if (modlist_lookup(found_modules, modname) != NULL
+ || modlist_lookup(file_modules, modname) != NULL) {
printf("module %s already present!\n", modname);
linker_file_unload(lf);
TAILQ_REMOVE(loaded_files, lf, loaded);
@@ -1064,9 +1052,38 @@
bzero(mod, sizeof(*mod));
mod-container = lf;
mod-name = modname;
- TAILQ_INSERT_TAIL(found_modules, mod, link);
+
Re: HEADSUP: bioops patch.
What about using uppercase names for buf_complete - BUF_COMPLETE and friends to make it apparent that an indirect call is being made and that the function might not be supported on that struct buf. Much like newbus, kobj, and vnode ops. Nick On Wed, 14 Jun 2000, Poul-Henning Kamp wrote: This patch virtualizes untangles the bioops operations vector. Background: The bioops operation vector is a list of OO-like operations which can be performed on struct buf. They are used by the softupdates code to handle dependencies. Ideally struct buf should have had a real OO like operations vector like vnodes have it, and struct bioops is the first step towards that. One of the reasons we should have OO-like struct buf, is that as long as bwrite(bp) "knows" that the buffer is backed by a disk device, we cannot use the UFS layer on top of a storage manager which isn't based on disk-devices: When UFS modifies a directory inode, it will call bwrite(bp) on the buffer with the data. This would not work if the backing were based on malloc(9) or anonymous swap-backed VM objects for instance. In other words: this is the main reason why we don't have a decent tmpfs in FreeBSD. Instead of just assuming that it works on a disk, bwrite(bp) should do a "bp-b_ops-bwrite(bp)" so that each buffer could have its own private idea of how to write itself, depending on what backing it has. So in order to move bioops closer to become a bp-b_ops, this patch takes two entries out of bioops: the "sync" and the "fsync" items and virtualizes the rest of the elements a bit. The "sync" item is called only from the syncer, and is a call to the softupdates code to do what it needs to do for periodic syncing. The real way of doing that would be to have an event-handler for this since other code could need to be part of the sync trafic, raid5 private parity caches could be one example. I have not done this yet, since currently softupdates is the only client. The fsync item really doesn't belong in the fsync system call, it belongs in ffs_fsync, and has been moved there. To give the right behaviour when SOFTUPDATES is not compiled in, stubs for both of these functions have been added to ffs_softdep_stub.c Finally all the checks to see if the bioops vector is populated has been centralized in in-line functions in sys/buf.h thereby paving the road for the global bioops to become bp-b_ops. Comments, reviews, tests please Poul-Henning Index: contrib/softupdates/ffs_softdep.c === RCS file: /home/ncvs/src/sys/contrib/softupdates/ffs_softdep.c,v retrieving revision 1.64 diff -u -r1.64 ffs_softdep.c --- contrib/softupdates/ffs_softdep.c 2000/05/26 02:01:59 1.64 +++ contrib/softupdates/ffs_softdep.c 2000/06/14 19:26:46 @@ -222,8 +222,6 @@ softdep_disk_io_initiation, /* io_start */ softdep_disk_write_complete,/* io_complete */ softdep_deallocate_dependencies,/* io_deallocate */ - softdep_fsync, /* io_fsync */ - softdep_process_worklist, /* io_sync */ softdep_move_dependencies, /* io_movedeps */ softdep_count_dependencies, /* io_countdeps */ }; Index: kern/vfs_bio.c === RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v retrieving revision 1.258 diff -u -r1.258 vfs_bio.c --- kern/vfs_bio.c2000/05/26 02:04:39 1.258 +++ kern/vfs_bio.c2000/06/14 19:00:56 @@ -616,8 +616,8 @@ newbp-b_flags = ~B_INVAL; /* move over the dependencies */ - if (LIST_FIRST(bp-b_dep) != NULL bioops.io_movedeps) - (*bioops.io_movedeps)(bp, newbp); + if (LIST_FIRST(bp-b_dep) != NULL) + buf_movedeps(bp, newbp); /* * Initiate write on the copy, release the original to @@ -673,10 +673,10 @@ /* * Process dependencies then return any unfinished ones. */ - if (LIST_FIRST(bp-b_dep) != NULL bioops.io_complete) - (*bioops.io_complete)(bp); - if (LIST_FIRST(bp-b_dep) != NULL bioops.io_movedeps) - (*bioops.io_movedeps)(bp, origbp); + if (LIST_FIRST(bp-b_dep) != NULL) + buf_complete(bp); + if (LIST_FIRST(bp-b_dep) != NULL) + buf_movedeps(bp, origbp); /* * Clear the BX_BKGRDINPROG flag in the original buffer * and awaken it if it is waiting for the write to complete. @@ -939,8 +939,8 @@ * cache the buffer. */ bp-b_flags |= B_INVAL; - if (LIST_FIRST(bp-b_dep) != NULL bioops.io_deallocate) - (*bioops.io_deallocate)(bp); + if (LIST_FIRST(bp-b_dep) != NULL) +
Re: cvsup on recent -CURRENT
Which host are you pilling from? I am slurping things out of ^^^ I've seen this post now three times and I still can't remember what word I wanted to use there. :-) It must be age I guess... Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvsup on recent -CURRENT
On this machine which runs -CURRENT from two days ago or so, I'm seeing frequent cvsup client failures of this type: TreeList failed: Network write failure: Connection closed I don't recall ever running into this before. Which host are you pilling from? I am slurping things out of cvsup.uk.freebsd.org and see the same messages. I thought it was crappy modem connection. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vn.ko load/unload/mount = panic
Correct me if I am wrong, but I don't think you actually have to
disassociate any dev_t's from the driver (by clearing the si_drv[12]
fields) because we call destroy_dev and cdevsw_remove, so any later uses
of dev_t's get an error because the device has gone away.
Apart from that I don't think we the calls to cdevsw_add/_destroy in the
first place, because we create the cdevsw on demand (with make_dev).
Poul, is this correct?
nick
On Fri, 28 Apr 2000, Peter Edwards wrote:
I had a longer look at this, and a more complete patch is logged as PR
kern/18270 (try at your own risk: it works for me).
I'd appreciate someone more experienced having a look at it and
commenting.
Cheers,
Peter.
Wilko Bulte wrote:
On Wed, Apr 26, 2000 at 04:25:46PM +0100, Peter Edwards (local) wrote:
How about send-pr ing this stuff?
Wilko
Hi,
After a (very) quick look at the source it looks like there's a missing
cdevsw_remove() missing from the MOD_UNLOAD/MOD_SHUTDOWN event handling
I haven't time to test it, but try this:
*** vn.c.oldWed Apr 26 16:23:03 2000
--- vn.cWed Apr 26 16:24:06 2000
***
*** 762,767
--- 762,768
case MOD_UNLOAD:
/* fall through */
case MOD_SHUTDOWN:
+ cdevsw_remove(vn_cdevsw);
for (;;) {
vn = SLIST_FIRST(vn_list);
if (!vn)
Maxim Sobolev wrote:
Hi,
I've already submitted this crash report earlier but it seems that developers
in -current list are too busy discussing whether Matt allowed to commit his SMP
work into 4.0 to pay attention to "ordinary" panic reports :-(. Following is
slightly simplified course of actions which is known to produce kernel panic on
both 4.0 and 5.0:
root@notebook# kldstat
Id Refs AddressSize Name
12 0xc010 1c2f48 kernel
21 0xc02c3000 30c8 splash_bmp.ko
root@notebook# mount /dev/vn0c /mnt
mount: Device not configured
root@notebook# kldload /modules/vn.ko
root@notebook# kldstat
Id Refs AddressSize Name
13 0xc010 1c2f48 kernel
21 0xc02c3000 30c8 splash_bmp.ko
31 0xc0823000 3000 vn.ko
root@notebook# kldunload -i 3
root@notebook# mount /dev/vn0c /mnt
[BINGO]
Fatal trap 12: page fault while in kernel mode
[...]
-Maxim
--
Wilko Bulte Powered by FreeBSD http://www.freebsd.org
http://www.tcja.nl
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] USB project
http://www.etla.net/~n_hibma/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: LINT broken. (in_cksum changes)
Appart from that, ipf does not load as a kld anymore. And probably, not tried, the IPFILTER option in any kernel would break the build as well. Nick On Mon, 8 May 2000, Wes Morgan wrote: I sent a note to the committer on these last night. LINT must need some modification, because the error is also present in netinet6/ipsec.c. There are some ifdef's around it that point to LINT needing some extra options. On Sun, 7 May 2000, Nick Hibma wrote: Is it only me that ever compiles LINT? The checksum changes went in a few days ago. Please, people, when you move code around or change a function that is used in more than a fixed set of files, compile LINT. If unsure, compile LINT. It's an extra five minutes, but well worth it. linking kernel fil.o: In function `fr_tcpsum': fil.o(.text+0xf47): undefined reference to `in_cksum' ip_fil.o: In function `send_reset': ip_fil.o(.text+0xd7d): undefined reference to `in_cksum' ip_fil.o: In function `ipfr_fastroute': ip_fil.o(.text+0x10f1): undefined reference to `in_cksum' ip_fil.o(.text+0x1316): undefined reference to `in_cksum' ip_fil.o(.text+0x1380): undefined reference to `in_cksum' ip_mroute.o(.text+0x19d6): more undefined references to `in_cksum' follow I just couldn't be bothered to fix it. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
LINT broken. (in_cksum changes)
Is it only me that ever compiles LINT? The checksum changes went in a few days ago. Please, people, when you move code around or change a function that is used in more than a fixed set of files, compile LINT. If unsure, compile LINT. It's an extra five minutes, but well worth it. linking kernel fil.o: In function `fr_tcpsum': fil.o(.text+0xf47): undefined reference to `in_cksum' ip_fil.o: In function `send_reset': ip_fil.o(.text+0xd7d): undefined reference to `in_cksum' ip_fil.o: In function `ipfr_fastroute': ip_fil.o(.text+0x10f1): undefined reference to `in_cksum' ip_fil.o(.text+0x1316): undefined reference to `in_cksum' ip_fil.o(.text+0x1380): undefined reference to `in_cksum' ip_mroute.o(.text+0x19d6): more undefined references to `in_cksum' follow I just couldn't be bothered to fix it. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic at boot (bus_generic_probe) with 2 printers ENABLED
Arg. What I really wanted to say was: When it drops into the debugger, type 'trace' without quotes. *sigh* /me wanders off in search for a brain On Fri, 5 May 2000, Nick Hibma wrote: No, could you add options DDB makeoptions DEBUG=-g to your kernel config and compile again? And reboot? When the kernel panics it will end up in the kernel debugger. When that happens, please write down the function names it comes up with. if there is a function called ppbus_attach in there, please write down its arguments as well. Nick On Sun, 30 Apr 2000, Jeroen Ruigrok van der Werven wrote: -On [2430 11:50], Leif Neland ([EMAIL PROTECTED]) wrote: In a freshly cvsup'ed current, I get a panic at boot, if both ports are enabled in userconfig. If only one or the other is enabled, it works. I have narrowed it down to it panics the second time ppbconf calls bus_generic_probe: trap 12: page fault while in kernel mode bus_generic_probe+0x25: cmpl $0xc02a502c,0(%ebx) ebx is 0xe0 How about adding: options BUS_DEBUG to your kernel config file and perhaps even boot verbose and show us the details of /var/log/messages? Thanks, -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED]VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Answering the questions that no one asks... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic at boot (bus_generic_probe) with 2 printers ENABLED
No, could you add options DDB makeoptions DEBUG=-g to your kernel config and compile again? And reboot? When the kernel panics it will end up in the kernel debugger. When that happens, please write down the function names it comes up with. if there is a function called ppbus_attach in there, please write down its arguments as well. Nick On Sun, 30 Apr 2000, Jeroen Ruigrok van der Werven wrote: -On [2430 11:50], Leif Neland ([EMAIL PROTECTED]) wrote: In a freshly cvsup'ed current, I get a panic at boot, if both ports are enabled in userconfig. If only one or the other is enabled, it works. I have narrowed it down to it panics the second time ppbconf calls bus_generic_probe: trap 12: page fault while in kernel mode bus_generic_probe+0x25: cmpl $0xc02a502c,0(%ebx) ebx is 0xe0 How about adding: options BUS_DEBUG to your kernel config file and perhaps even boot verbose and show us the details of /var/log/messages? Thanks, -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED]VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Answering the questions that no one asks... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern/16767 [PATCH] (A.K.A. Re: Geek Port crash)
You seem to have put in some hard work there. Yes, your analysis is
correct. the problem has been corrected not so long ago, albeit in a
slightly different way.
As it is now the ppi bus does not attach if the bus is polled mode. But
you are saying it works in polled mode as well.
I've attached a patch that only enables the alloc and setup of the irq
in the case where PERIPH_1284 is defined. If that is defined, then the
irq alloc is attempted, but if it fails, your patch kicks in and does
not set it up in ppiopen.
The patch is against current as of 2000-05-05, so you will have
to update that part of the source. If this is not an option for
you, let me know and send me the output of ident ppi.c, so I can
make a patch for you. Mike, please let me know if this works for you.
Nicolas, could you tell me whether this is the correct thing to do? the
thing that I think is missing is somehow the possibility to use
'interrupts' even in polled mode. Basically the ppbus should simulate
the interrupt by calling the interrupt after a poll has decided that an
interrupt has occurred.
Mike, well done!
Nick
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] USB project
http://www.etla.net/~n_hibma/
Index: ppi.c
===
RCS file: /home/ncvs/src/sys/dev/ppbus/ppi.c,v
retrieving revision 1.22
diff -w -u -r1.22 ppi.c
--- ppi.c 2000/04/07 00:09:24 1.22
+++ ppi.c 2000/05/05 14:27:26
@@ -68,8 +68,10 @@
intppi_mode; /* IEEE1284 mode */
char ppi_buffer[BUFSIZE];
+#ifdef PERIPH_1284
struct resource *intr_resource;/* interrupt resource */
void *intr_cookie; /* interrupt registration cookie */
+#endif /* PERIPH_1284 */
};
#define DEVTOSOFTC(dev) \
@@ -170,13 +172,11 @@
/* retrive the irq */
BUS_READ_IVAR(device_get_parent(dev), dev, PPBUS_IVAR_IRQ, irq);
+#ifdef PERIPH_1284
/* declare our interrupt handler */
ppi-intr_resource = bus_alloc_resource(dev, SYS_RES_IRQ,
zero, irq, irq, 1, RF_ACTIVE);
- if (ppi-intr_resource == NULL) {
- device_printf(dev, "can't allocate irq\n");
- return (ENOMEM);
- }
+#endif /* PERIPH_1284 */
make_dev(ppi_cdevsw, device_get_unit(dev), /* XXX cleanup */
UID_ROOT, GID_WHEEL,
@@ -276,9 +276,13 @@
ppi-ppi_flags |= HAVE_PPBUS;
+#ifdef PERIPH_1284
+ if (ppi-intr_resource) {
/* register our interrupt handler */
BUS_SETUP_INTR(device_get_parent(ppidev), ppidev, ppi-intr_resource,
INTR_TYPE_TTY, ppiintr, dev, ppi-intr_cookie);
+ }
+#endif /* PERIPH_1284 */
}
ppi-ppi_count += 1;
Re: kernel panic at boot with 2 printers
Could you compile a debugging kernel with the kernel debugger included and make it bomb again, and write down the function names that the trace command on the DDB command line gives you and the exact trap message? Thanks in advance. Nik On Fri, 28 Apr 2000, Leif Neland wrote: Sorry not to have details at hand but anyways: Current cvsupped today. I have 2 parallel ports in use. I have had no problems with kernels dated 2 weeks or older, but since a few days ago, the system crashes at boot while probing the parallel ports. "Page fault while in supervisor mode", (I seem to remember vaguely) If I disable either lpt0 or lpt1 in -c config, the system boots and operates without problems. I know this is a terrible bug-report, but perhaps it still could trigger the memory of whoever made changes to the printer system I can provide better info tomorrow if needed, but it's so late I can't find a pencil to write the exact messages. 'night Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Strange phenomen accessing a CDROM contents under linuxerator
The one directory I can remember that was missing from the acroread file selector was a symbolic link (to the directory with the documents I wanted of course :-). /usr/export was not found, but /usr/export/usb was found when typed in in the top edit box. I see the same thing on 4.0-STABLE, so far only using linux-netscape. When I go to select a directory for download, or when accessing an HTML file to be opened, certain directories always appear to be missing. Only one that comes to mind at the moment is the ports directory when looking in /usr. -- Walter Brameld Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? BSD: Are you guys coming, or what? Walter:And what does THIS button do?? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP problem? (was: Re: [usb-bsd] USB To Do list)
uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xe000-0xe01f irq 15 at device 7.2 on pci0 uhci0: LegSup = 0x0010 ^^ PIRQDEN (IRQ's Enable) bit is not set by default. We set it right afterwards, but you you might want to check this out by copying the device_printf. The value should be 0x2000. In uhci_pci.c: * anymore if it is connected to the ports of the root hub? */ #ifdef UHCI_DEBUG if (pci_read_config(self, PCI_LEGSUP, 4)!=PCI_LEGSUP_USBPIRQDEN) device_printf(self, "LegSup = 0x%08x\n", pci_read_config(self, PCI_LEGSUP, 4)); #endif pci_write_config(self, PCI_LEGSUP, PCI_LEGSUP_USBPIRQDEN, 4); + device_printf(self, "LegSup = 0x%08x\n", + pci_read_config(self, PCI_LEGSUP, 4)); err = uhci_init(sc); Shared interrupt? No shared interrupt. Both IDE channels are disabled by BIOS, thus, irq 15 is free. After all, The USB drivers work if I run a UP kernel on the same machine. Um, no, it still might conflict. Could you assign 14 and 15 to legacy ISA, or move the UHCI controller onto a different interrupt and try again? I know. It works on my another SMP box running 4.0-STABLE ;- There is no difference between 5.0 nd 4.0 that could create this problem, so it must be a difference in hardware. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
USB To Do list
If've put up a list of things that need to be done still in the FreeBSD USB stack. The list is _big_. I'll be adding things as they come up. http://www.etla.net/~n_hibma/usb/usb.pl A lot of the items are not that difficult to do and if you feel like taking up a little project, start working on something and send patches/source as you work through them. It might change the short term priority list a bit to include your toy :-) The Todo list is included below. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Do list for the USB project: Let meknow if you would like to participate in any way, or you have done one of the items below! - Short term priority list - Finish off the import of the urio driver. Update the license in rio500_usb.h. - Finish the synchronisation with NetBSD - Split umass into two parts: wire (BBB, CBI) and command protocols - Investigate panic on close of interrupt pipe with low frequency. - Finally checkout the umodem driver and include it in the tree. - USB base stack and general items. - Fix/check suspend on UHCI and OHCI controllers, especially on laptops. - Use a kthread to handle the 'Done Queue'. - OHCI connection problems - Check out the manpages available. Add new ones where appropriate. - Generic driver should be available for all devices, not only for the ones that nothing else attaches to. - Possibility of locking pipes, interfaces amp; devices to make sure no concurrent accesses are done (confusing a device, e.g. e-shuttle USB) - Implement poll/select for generic device. Idea: When select is called for reading and no read is in progress a read for MaxPacketSize with SHORT PACKET OK set is initiated. Select for writing always succeeds. - One shot transfers on interrupt pipes (needed for 'bulk' outs on low speed devices for example). - USB userland utility (usbcontrol) - The word 'class' is used in usb.h. This is a problem for c++ compilers. Change the whole interface for usbdevs/usbd to something sensible. - Create a usbcontrol util combining all the functionality of usb_dump.c, usbdevs and the usb*something* utility in NetBSD into one. - USB Serial port driver (usio) driver (by Doug Ambrisko) - Check out the version of sdcc that is in ports nowadays. - Check out which dongles the usio driver works with - Usio manpage. - USB Mass Storage (umass) driver - Check out the file system corruption problems under heavy load / added load of a USB ethernet dongle. - Check out support for ATAPI devices. - Convert Read/Write_6 to Read/Write_10 in transform. This avoids having to quirk every single UFI compliant device. - USB Keyboards - Keyboard in DDB debugger does not work. - USB printer port support - Bi-directional support - Is the manual page up to date? Does it specify all the flags you can set on the device minor number? - Related: - PCI/USB/PCCard/PCMCIA/other vendor, product and revision Id matching code should be made generic, so that drivers can match in a more generic way. The ID's should be collected into one location to make the addition of new Id's more generic. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [usb-bsd] USB To Do list
- USB Keyboards - Keyboard in DDB debugger does not work. In what configuration does it not work? I can use my USB keyboard in DDB without problems on a dual PPro box (4.0-STABLE) with a UHCI controller (VIA 83c572) card and a Pentium box (3.4-STABLE) with Intel PIIX3 here... I've seen it run away like mad (like pressing Return a hundred times a second). Maybe that was just a glitch (on UHCI hardware). I've seen this same behaviour on an iMac running NetBSD. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP problem? (was: Re: [usb-bsd] USB To Do list)
What does it say before this info? Shared interrupt? USB does work on SMP (or at least in some cases). uhci_timeout: ii=0xc0a601c0 uhci_timeout: ii=0xc0a601c0 uhci_timeout: ii=0xc0a601c0 usbd_new_device: addr=2, getting first desc failed uhub_explore: usb_new_device failed, error=TIMEOUT uhub0: device problem, disabling port 1 I vaguely remember someone also reported similar problems with the SMP kernel in the past Interesting thing is that I have another SMP box, and its USB works fine. The version is 4.0-STABLE. The USB controller is VIA 83c572. Kazu @Backup- Protect and Access your data any time, any where on the net. Try @Backup FREE and recieve 300 points from mypoints.com Install now: http://click.egroups.com/1/2345/6/_/85983/_/955110182/ -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl 5.6.0?
Could we stop this nonsense thread now? No one is against it. The only reason why it is not in the tree is that no one has the time to actually implement the change. If someone wants it in the tree, do the work and submit it to the current maintainer of Perl in FreeBSD. Thanks in advance. Nick On Thu, 6 Apr 2000, Alexander N. Kabaev wrote: According to OpenBSD ournal site, OpenBSD-current has perl 5.6.0 in it's source tree already. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dev/vx/if_vx_pci.c 5.0-CURRENT
You really want to look at other drivers, how they have been done. When you are done, send me the diff and I will have a look at it. It is fairly straightforward to convert from one to the other, once you have understood both concepts a bit. Nick On Wed, 5 Apr 2000, Eric D. Futch wrote: I figured it would take more work than I put into it. It was just a shot in the dark. I think I have one of these cars in my Linux box at home which I wouldn't mind ripping out and sticking in this machine. Let me know if it's still worth me poking around in, or if you're going ahead with the rewrite. I'm gonna keep playing with it out of my own interest on newbusifying things. Maybe once I get a bigger clue of what has to be done, I'll see about newbusifying other things. I always have all this extra time on my hands :) -- Eric Futch New York Connect.Net, Ltd. [EMAIL PROTECTED] Technical Support Staff http://www.nyct.net (212) 293-2620 "Bringing New York The Internet Access It Deserves" On Wed, 5 Apr 2000, Brooks Davis wrote: On Wed, Apr 05, 2000 at 08:43:30PM -0400, Eric D. Futch wrote: I think if you install the kernel and reboot it will likely explode in probe. It takes more then just new structs. The function signatures have changed as well. Take a look at rev 1.67 of src/sys/pci/if_fxp.c to see what newbus conversion takes. I'm taking a wack at a rewrite, but like you I don't have a card, so testing will be kinda trickey. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB/Orb/kue/iopener/filesystem corruption
Why does this sound like the warning that is written in the manual of the Iomega Zip drive: do not connect more than one Zip drive to the same USB host data might corrupted. Or something similar... But.. but.. I only have the one drive connected. It could be that heavy Bulk traffic gives data corruption on the wire. I've not been able to track what they meant when they said that some parts do not correctly check CRC. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Parallel port zip drives - inventory of working and non-workingsystems
Could anyone who uses a Parallel Zip drive with FreeBSD 4.0 and up ('and
better' I almost wrote there :-) send me a message wether it works?
I'm trying to resolve PR 16153, but have no clue where to look
If it does not work, please tell me
- what version of the OS you are using
- at which point it stoppped working (date, version of FreeBSD, which
upgrade step, etc.)
- if possible and you are willing, please send me the output dmesg as an
attachment.
Thanks in advance!
Nick
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] USB project
http://www.etla.net/~n_hibma/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
