Help:why bus resource shortage?
Hi guys: I failed to get the pci bus resource after the driver is loaded (sc-r_mem is NULL after bus_alloc_resource_any is called). Is it because bus resources have been consumed by other drivers? Or other something happened? Please help me on this! Thanks! Hong Notes: /* get resources */ rid = 0x10; sc-r_mem = bus_alloc_resource_any(sc-dev, SYS_RES_MEMORY, rid, RF_ACTIVE); if (!sc-r_mem) return ENOMEM; The pci resources on our cards: shasta0: Promise FastTrak 4310/579/779 Driver port 0x2400-0x247f, 0x2000-0x20ff mem 0xe9021000-0xe9021fff, 0xe900-0xe901 irq 17 at device 5.0 on pci2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Options for boot program
My way of operating is to multi-task almost all the time. As such, while working on one task, if another task on which I am also working (but had to pause in it because some information or equipment that the task needed wasn't available) of higher priority suddenly became available/operable, then I would want to know about this so that I could switch to the higher priority task. Thus I want that the computer should tell me that it needs input for one of its tasks, or that some task is showing output that I may want to see (this usually means error messages rather than standard output). The best way for the computer to tell me these things (i.e., to call my attention to itself) is by sound (because the ear detects from all around, while the eye detects only from in front of itself [so I would have to be looking at the screen]). Thus I can do other things and be called back to the computer as needed. Hence I want the boot program to sound a bell (possibly several times with a short interval to wait between successive times, and proceed immediately when I respond [and not wait for a set # of bells to be sounded]) if it is waiting for input (say, as to which slice to boot), and the amount of time (in seconds) that it waits for that input, and if it doesn't get any input before this time period expires, it boots the current default slice. I want to set the length of this time period (to wait before booting the current default slice). I realize that other users of the boot program may want it to behave differently than I do. Consequently, each user should be able to tell the boot program how he wants it to behave regarding these matters, and other matters that some user may be able to describe. A programmer of the boot program should not impose his preferences on the users of the boot program, but code in a way that allows them to get their preferred operation from the boot program. This can't be easily/safely done by options in the call of the boot program because the boot program isn't called (as we are familiar with it). It is read into RAM from the boot sector and then control is transferred to it, and all this is done by the BIOS or a small program built into the hardware of a computer. One way to make the boot program aware of a user's preferences is to store these preferences (options) in the boot sector, say the last byte or two of that sector. That way, this data will not have a chance of being in the midst of code. The setting of these bytes can be done as part of the installation of the boot program, and/or have a special patch program that patches just this area (even after installation so if the owner wants to change his options after installation, he can easily do so). I would like to suggest some minor changes to the boot program for FreeBSD , mainly in the area of options that the user can set when installing it. Hopefully the space available for the boot program will be big enough to allow these changes. By the way, is there more space available (e.g., more sectors on the platter/cylinder) for the boot program? Where can one get the code for the boot? Also, how much space is available for the boot code? Also, can one add more slices (so there are more than 4) to the system, and have ways of booting them. Another thing that could be done is to introduce logical slice (the term has been used before), say by allowing more than 8 partitions per slice and allowing the user to be able to specify which set of 5 to mount (and these 5 form a logical slice). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Options for boot program
On Thu, 15 Jun 2006 07:02:11 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: My way of operating is to multi-task almost all the time [...] Hence I want the boot program to sound a bell (possibly several times with a short interval to wait between successive times, and proceed immediately when I respond [and not wait for a set # of bells to be sounded]) if it is waiting for input [...] I realize that other users of the boot program may want it to behave differently than I do. Consequently, each user should be able to tell the boot program how he wants it to behave regarding these matters, and other matters that some user may be able to describe [...] One way to make the boot program aware of a user's preferences is to store these preferences (options) in the boot sector [...] I apologise in advance if excessive snipping was done above, but I tried to keep your major points intact. I don't think it is a good idea to try to cram more features in the severely limited space the boot0 stage currently has. The entire boot0 object code should fit in less than 512 bytes (some of that space is used to store the BIOS-partition table too). Adding more and more features every time we want to extend it will quickly make it either buggy or unusable for the majority of the people who currently use it. On the other hand, there are other boot managers, which can use more space and are not as limited. It may be a good idea to try one of those and extend it to cover your needs. A very featureful and nice option is GRUB, which -AFAIK- currently supports Windows, Linux, FreeBSD, Solaris and a few other OSes. Unfortunately, the GRUB port of FreeBSD is i386-only, so if you are running something else (sparc64 or amd64), it is impossible to use it. I'd put my own money into porting GRUB to work with all the major architectures currently supported by FreeBSD. Then, I would add the features you like to GRUB, which already includes an extended set of configuration options and can easily incorporate more. I would like to suggest some minor changes to the boot program for FreeBSD , mainly in the area of options that the user can set when installing it. Hopefully the space available for the boot program will be big enough to allow these changes. By the way, is there more space available (e.g., more sectors on the platter/cylinder) for the boot program? Not much space is available. Where can one get the code for the boot? The source code for the boot0-stage loader is: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/boot0/boot0.S Also, how much space is available for the boot code? A very small number of bytes. Forget about this, if you ask me... - Giorgos ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help:why bus resource shortage?
2006/6/15, [EMAIL PROTECTED] [EMAIL PROTECTED]: Hi guys: I failed to get the pci bus resource after the driver is loaded (sc-r_mem is NULL after bus_alloc_resource_any is called). Is it because bus resources have been consumed by other drivers? Or other something happened? Please help me on this! Thanks! Hong Notes: /* get resources */ rid = 0x10; sc-r_mem = bus_alloc_resource_any(sc-dev, SYS_RES_MEMORY, rid, RF_ACTIVE); if (!sc-r_mem) return ENOMEM; The pci resources on our cards: shasta0: Promise FastTrak 4310/579/779 Driver port 0x2400-0x247f, 0x2000-0x20ff mem 0xe9021000-0xe9021fff, 0xe900-0xe901 irq 17 at device 5.0 on pci2 I suspect your PCI BAR pointer is wrong. Are you sure about its value? Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
interfacing uhid devs from kernel module
Hello Is it possible to use functions from libusbhid in kernel module? It would really ease some things for me, but I realize it is a userland library. Still, is there some way to do this? Bye Marcin Cylke ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interfacing uhid devs from kernel module
On Thursday 15 June 2006 16:04, Marcin Cylke wrote: Hello Is it possible to use functions from libusbhid in kernel module? It would really ease some things for me, but I realize it is a userland library. Still, is there some way to do this? What functions do you need? Have you looked at uhid.c under /sys/dev/usb ? --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fdisk partition / disklabel recovery (help!)
On Tue, 2006-06-13 at 23:54 -0400, Naram Qashat wrote: You've also got the choice of using the program testdisk in sysutils/testdisk to try to fix your problem. It helped me when I accidently hosed the MBR and partition table on one of my drives. I second this (because it saved my life, not because I'm the maintainer). -- Florent Thoumie [EMAIL PROTECTED] FreeBSD Committer signature.asc Description: This is a digitally signed message part
ipw3945 intel wireless miniPCI
Hi Hackers, Did anyone manage to get this card working under FreeBSD? I'm using FreeBSD 6.1_REL0 on my laptop. I know the /usr/ports/net-firmware/ is for IPW2100. Doesn't appear to work on 3945. I know about ipw3945.sourceforge.net, there's an opensource stable driver for linux. Any help/tip is greatly appreciated. Thanks. Yours, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA It is dangerous to be right when the government is wrong. - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipw3945 intel wireless miniPCI
On Thu, Jun 15, 2006 at 05:56:41PM +0300, Alin-Adrian Anton wrote: Hi Hackers, Did anyone manage to get this card working under FreeBSD? I'm using FreeBSD 6.1_REL0 on my laptop. I know the /usr/ports/net-firmware/ is for IPW2100. Doesn't appear to work on 3945. I know about ipw3945.sourceforge.net, there's an opensource stable driver for linux. Any help/tip is greatly appreciated. Thanks. Unfortunately there is no support in FreeBSD for this chip yet. OpenBSD has support for it in CURRENT in form of the wpi(4) driver. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgpeJeFUehLyi.pgp Description: PGP signature
Re: interfacing uhid devs from kernel module
On 6/15/06, Hans Petter Selasky [EMAIL PROTECTED] wrote: What functions do you need? Have you looked at uhid.c under /sys/dev/usb ? I would like to use the whole infrastructure: struct hid_item hid_usage_page() hid_usage_in_page() hid_init() hid_get_report_desc() Bye ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interfacing uhid devs from kernel module
2006/6/15, Marcin Cylke [EMAIL PROTECTED]: On 6/15/06, Hans Petter Selasky [EMAIL PROTECTED] wrote: What functions do you need? Have you looked at uhid.c under /sys/dev/usb ? I would like to use the whole infrastructure: struct hid_item hid_usage_page() hid_usage_in_page() hid_init() hid_get_report_desc() Give a look at USB mouse (ums.c) which give a good overview about HID kernelspace API. However I don't know if Hans has plans to change it in the new stack... Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interfacing uhid devs from kernel module
On Thursday 15 June 2006 19:02, Attilio Rao wrote: 2006/6/15, Marcin Cylke [EMAIL PROTECTED]: On 6/15/06, Hans Petter Selasky [EMAIL PROTECTED] wrote: What functions do you need? Have you looked at uhid.c under /sys/dev/usb ? I would like to use the whole infrastructure: struct hid_item hid_usage_page() hid_usage_in_page() hid_init() hid_get_report_desc() Give a look at USB mouse (ums.c) which give a good overview about HID kernelspace API. However I don't know if Hans has plans to change it in the new stack... I have changed it a little bit, but I don't have any plans to change it further. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: apic detection
On Wednesday 14 June 2006 12:33, Andriy Gapon wrote: What is proper way to check from a driver/module if APIC is being used ? Or even narrower, if local APIC timer is being used ? There isn't currently. Why do you need to know? -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: apic detection
on 15/06/2006 20:10 John Baldwin said the following: On Wednesday 14 June 2006 12:33, Andriy Gapon wrote: What is proper way to check from a driver/module if APIC is being used ? Or even narrower, if local APIC timer is being used ? There isn't currently. Why do you need to know? There is a driver that I am working on that could change frequency of local APIC timer by changing FSB frequency and I want to make that driver smarter and refuse to attach if local APIC timer is used. I know that in 6.X and CURRENT local APIC timer is always used and in 5.X it is never used, but I want my driver to handle environment more generally. I am thinking, can I just somehow check if IRQ0 is in use ? Would it be something close to proper solution ? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Options for boot program
I can identify with your condition. :) Unfortunately, the early boot loaders (boot0, and boot1+boot2) are simply too tight on space to add more features. I think boot0 literally has 0 or 1 bytes free right now. However /boot/loader has a lot more free space and can be easily and intuitively configured via /boot/loader.conf. All of the boot code can be found under src/sys/boot. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipw3945 intel wireless miniPCI
On Thu, Jun 15, 2006 at 05:51:01PM +0200, Christian Brueffer wrote: On Thu, Jun 15, 2006 at 05:56:41PM +0300, Alin-Adrian Anton wrote: Hi Hackers, Did anyone manage to get this card working under FreeBSD? I'm using FreeBSD 6.1_REL0 on my laptop. I know the /usr/ports/net-firmware/ is for IPW2100. Doesn't appear to work on 3945. I know about ipw3945.sourceforge.net, there's an opensource stable driver for linux. Any help/tip is greatly appreciated. Thanks. Unfortunately there is no support in FreeBSD for this chip yet. OpenBSD has support for it in CURRENT in form of the wpi(4) driver. That should read the OpenBSD driver is still very much a work in progress, so don't get your hopes too high. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgpVE13jPmGb4.pgp Description: PGP signature
Re: Options for boot program
I don't know why I was included in the CC list for this thread, nor do I have any input on the subject. Please trim my address from the CC list. Thanks. -- Darren Pilgrim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: apic detection
On Thursday 15 June 2006 14:23, Andriy Gapon wrote: on 15/06/2006 20:10 John Baldwin said the following: On Wednesday 14 June 2006 12:33, Andriy Gapon wrote: What is proper way to check from a driver/module if APIC is being used ? Or even narrower, if local APIC timer is being used ? There isn't currently. Why do you need to know? There is a driver that I am working on that could change frequency of local APIC timer by changing FSB frequency and I want to make that driver smarter and refuse to attach if local APIC timer is used. I know that in 6.X and CURRENT local APIC timer is always used and in 5.X it is never used, but I want my driver to handle environment more generally. It it always used if APIC is used. I am thinking, can I just somehow check if IRQ0 is in use ? Would it be something close to proper solution ? On x86 there is a variable called 'using_lapic_timer' that is available in sys/i386/isa/clock.c (and the amd64 equivalent), but I think it is static to that file, so you probably can't get to it. Other than that there really isn't a current way to know as the vast majority of the system does not (and should not) know or care. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stack frame problem in gdb
On Tue, May 16, 2006 at 11:12:40AM +0400, Yar Tikhiy wrote:
Has our stock GDB lost the ability to set the current stack frame
by its address? In 4.11-STABLE, the old recipe from the Developer's
Handbook still works:
frame frame_addr instruction_ptr
Alas, it no longer works in RELENG_6 or CURRENT (tested on i386 and
amd64.) A sample typescript is attached. It boils down to the
following: The frame command accepts one argument at most in the
new GDB, which is taken for the address of a frame if it's sufficiently
large. Refusing now to read the instruction pointer value from the
command line, GDB sets it to 0 -- a smart guess, damn it. Finally,
GDB crashes on the bogus frame it made up.
It seems to be a genuine GDB 6 i386 bug reported as early as in
2002: http://sourceware.org/ml/gdb/2002-11/msg00263.html. It
exists in Linux, too, as tested in Debian with GDB 6.3.
Moreover, GDB 6 fails to assign correct addresses to stack frames.
This might be related to the former issue, as testing on alpha
showed (see below.)
Does anybody know GDB folks who can help in fixing the issues?
Example:
%%% GDB 6 i386 %%%
(gdb) i f 2
Stack frame at 0xbfbfeca8:
eip = 0x80484ac in b (test.c:13); saved eip 0x80484b8
called by frame at 0xbfbfecb0, caller of frame at 0xbfbfeca0
source language c.
Arglist at 0xbfbfeca0, args:
Locals at 0xbfbfeca0, Previous frame's sp is 0xbfbfeca8
Saved registers:
ebp at 0xbfbfeca0, eip at 0xbfbfeca4
(gdb) i f 3
Stack frame at 0xbfbfecb0:
eip = 0x80484b8 in c (test.c:18); saved eip 0x80484dd
called by frame at 0xbfbfecd0, caller of frame at 0xbfbfeca8
source language c.
Arglist at 0xbfbfeca8, args:
Locals at 0xbfbfeca8, Previous frame's sp is 0xbfbfecb0
Saved registers:
ebp at 0xbfbfeca8, eip at 0xbfbfecac
### The frame addresses were off by one frame. It was a coincidence,
### as the following tests on alpha will show. The addresses are just
### bogus.
%%% GDB 6 alpha %%%
(gdb) i f 2
Stack frame at 0x11ffeb80:
pc = 0x1287c in b (test.c:13); saved pc 0x128ac
called by frame at 0x11ffeb90, caller of frame at 0x11ffeb70
source language c.
Arglist at 0x11ffeb80, args:
Locals at 0x11ffeb80, Previous frame's sp is 0x11ffeb80
Saved registers:
fp at 0x11ffeb78, ra at 0x11ffeb70, pc at 0x11ffeb70
(gdb) i f 3
Stack frame at 0x11ffeb90:
pc = 0x128ac in c (test.c:18); saved pc 0x128dc
called by frame at 0x11ffeba0, caller of frame at 0x11ffeb80
source language c.
Arglist at 0x11ffeb90, args:
Locals at 0x11ffeb90, Previous frame's sp is 0x11ffeb90
Saved registers:
fp at 0x11ffeb88, ra at 0x11ffeb80, pc at 0x11ffeb80
### The frame addresses were just bogus.
### Let's look at frame 2 by its address:
(gdb) i f 0x11ffeb80 0x1287c
Stack frame at 0x11ffeb80:
pc = 0x1287c in b (test.c:14); saved pc 0x1284c
called by frame at 0x11ffeb70
source language c.
Arglist at 0x11ffeb60, args:
Locals at 0x11ffeb60, Previous frame's sp is 0x11ffeb60
Saved registers:
fp at 0x11ffeb58, ra at 0x11ffeb50, pc at 0x11ffeb50
### It's not frame 2! Which frame is it?..
(gdb) i f 0
Stack frame at 0x11ffeb60:
pc = 0x12810 in x (test.c:3); saved pc 0x1284c
called by frame at 0x11ffeb70
source language c.
Arglist at 0x11ffeb60, args:
Locals at 0x11ffeb60, Previous frame's sp is 0x11ffeb60
Saved registers:
fp at 0x11ffeb58, ra at 0x11ffeb50, pc at 0x11ffeb50
### Oops, GDB showed us frame 0 when we tried to look at
### the frame @ 0x11ffeb80!
%%% GDB 4 i386 %%%
(gdb) i f 2
Stack frame at 0xbfbff6f0:
eip = 0x804849f in b (test.c:13); saved eip 0x80484b7
called by frame at 0xbfbff700, caller of frame at 0xbfbff6e0
source language c.
Arglist at 0xbfbff6f0, args:
Locals at 0xbfbff6f0, Previous frame's sp is 0x0
Saved registers:
ebp at 0xbfbff6f0, eip at 0xbfbff6f4
(gdb) i f 3
Stack frame at 0xbfbff700:
eip = 0x80484b7 in c (test.c:18); saved eip 0x80484cf
called by frame at 0xbfbff710, caller of frame at 0xbfbff6f0
source language c.
Arglist at 0xbfbff700, args:
Locals at 0xbfbff700, Previous frame's sp is 0x0
Saved registers:
ebp at 0xbfbff700, eip at 0xbfbff704
### The good old GDB 4 was working OK...
--
Yar
P.S. The program used for the tests was as follows:
x()
{
return 1;
}
a()
{
return x();
}
b()
{
return a();
}
c()
{
return b();
}
main()
{
return c();
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipw3945 intel wireless miniPCI
Christian Brueffer wrote: On Thu, Jun 15, 2006 at 05:56:41PM +0300, Alin-Adrian Anton wrote: Hi Hackers, Did anyone manage to get this card working under FreeBSD? I'm using FreeBSD 6.1_REL0 on my laptop. I know the /usr/ports/net-firmware/ is for IPW2100. Doesn't appear to work on 3945. I know about ipw3945.sourceforge.net, there's an opensource stable driver for linux. Any help/tip is greatly appreciated. Thanks. Unfortunately there is no support in FreeBSD for this chip yet. OpenBSD has support for it in CURRENT in form of the wpi(4) driver. - Christian Thank you for the information. Regards, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA It is dangerous to be right when the government is wrong. - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
