mmap on emulated i386
Hi, I'm trying to figure out why the following fails when compiled on amd64 with -m32: mmap(NULL, 0x7, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_ANON|MAP_PRIVATE, -1, 0); It returns EINVAL. I looked around everywhere but I couldn't find where the EINVAL is coming from. The length argument doesn't really make any difference. At this point I'm thinking it's a bug... -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: how to make a etc/rc.d start at boot time
On 10 Aug 2013, at 22:31, Aryeh Friedman aryeh.fried...@gmail.com wrote: I am creating a port for something that needs to start a daemon at boot time I have it so I can call onestart on it but XXX_enable=YES in /etc/rc.conf fails to load it i.e. /usr/local/etc/rc.d/XXX onestart -- works XXX_enable=YES -- fails Please post your script. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On 17 Nov 2012, at 23:05, Perry Hutchison per...@pluto.rain.com wrote:
[trimmed some of the lists]
Chris Rees utis...@gmail.com wrote:
... git doesn't work with our workflow.
I'm sure the workflow itself is documented somewhere, but is
there a good writeup of _how_ git doesn't work with it, e.g. what
capabilit{y,ies} is/are missing? Seems this might be of interest
to the git developers, not because they necessarily want to support
FreeBSD as such, but as an example of a real-world workflow that git
currently does not handle well.
Peter had something to say about it:
http://wiki.freebsd.org/GitDrawbacks
Regards,
--
Rui Paulo
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: clang mangling some static struct names?
On 16 Nov 2012, at 14:04, Navdeep Parhar npar...@gmail.com wrote:
On 11/16/12 13:49, Roman Divacky wrote:
Yes, it does that. iirc so that you can have things like
void foo(int cond) {
if (cond) {
static int i = 7;
} else {
static int i = 8;
}
}
working correctly.
It's not appending the .n everywhere. And when it does, I don't see any
potential collision that it prevented by doing so. Instead, it looks
like the .n symbol corresponds to the nth element in the structure (so
this is not name mangling in the true sense). I just don't see the
point in doing things this way. It is only making things harder for
debuggers.
It's likely that FreeBSD's gdb has to grow support for this new symbol format.
Have you tried using the newest gdb available from ports?
Regards,
--
Rui Paulo
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Removal of libobjc
On 15 Oct 2010, at 20:19, Roman Divacky wrote: On Fri, Oct 15, 2010 at 08:15:52PM +0100, Rui Paulo wrote: Hi, I was hoping we could remove libobjc from the base system as it's seriously outdated and it's not used by anything on the base system. If there are any objections, please speak up. please wait until the ports are converted to use libobjc2 (already in progress).. it should be a few days/weeks at most now I think Yes, I was just asking if someone was against it. Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Removal of libobjc
Hi, I was hoping we could remove libobjc from the base system as it's seriously outdated and it's not used by anything on the base system. If there are any objections, please speak up. Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Intel TurboBoost in practice
On 24 Jul 2010, at 14:53, Alexander Motin wrote: Hi. I've make small observations of Intel TurboBoost technology under FreeBSD. This technology allows Intel Core i5/i7 CPUs to rise frequency of some cores if other cores are idle and power/thermal conditions permit. CPU core counted as idle, if it has been put into C3 or deeper power state (may reflect ACPI C2/C3 states). So to reach maximal effectiveness, some tuning may be needed. Here is my test case: FreeBSD 9-CURRENT on Core i5 650 CPU, 3.2GHz + 1/2 TurboBoost steps (+133/+266MHz) with boxed cooler at the open air. I was measuring building time of the net/mpd5 from sources, using only one CPU core (cpuset -l 0 time make). Untuned system (hz=1000): 14.15 sec Enabled ACPI C2 (hz=1000+C2): 13.85 sec Enabled ACPI C3 (hz=1000+C3): 13.91 sec Reduced HZ (hz=100): 14.16 sec Enabled ACPI C2 (hz=100+C2): 13.85 sec Enabled ACPI C3 (hz=100+C3): 13.86 sec Timers tuned* (hz=100): 14.10 sec Enabled ACPI C2 (hz=100+C2): 13.71 sec Enabled ACPI C3 (hz=100+C3): 13.73 sec All numbers tested few times and are repeatable up to +/-0.01sec. *) Timers were tuned to reduce interrupt rates and respectively increase idle cores sleep time. These lines were added to loader.conf: sysctl kern.eventtimer.timer1=i8254 sysctl kern.eventtimer.timer2=NONE kern.eventtimer.singlemul=1 kern.hz=100 PS: In this case benefit is small, but it is the least that can be achieved, depending on CPU model. Some models allow frequency to be risen by up to 6 steps (+798MHz). The numbers that you are showing doesn't show much difference. Have you tried buildworld? PPS: I expect even better effect achieved by further reducing interrupt rates on idle CPUs. -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org Use the link below to report this message as spam. https://lavabit.com/apps/teacher?sig=1225540key=3283483970 Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: amd64 kernel modules: mapping sections to addresses
On 25 Jun 2010, at 10:28, Andriy Gapon wrote: Here's a patch that is supposed to do the right thing for dtrace. Perhaps I should have put the new code under __amd64__, but I decided to go more generic and check for module's ELF type (ET_REL). Reviews and testing are welcome! I believe this is good to go. Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Activate PCIe slot deactivated by BIOS
On 26 May 2010, at 07:55, Dominic Fandrey kamik...@bsdforen.de wrote: On 25/05/2010 13:57, Rui Paulo wrote: On 22 May 2010, at 13:27, Dominic Fandrey wrote: On 22/05/2010 13:47, Dominic Fandrey wrote: Today the card arrived and the BIOS complains (HP 6510b): 104-Unsupported wireless network device detected. System halted. Remove device and restart. The system boots if I turn off the wireless device in BIOS, but this means I cannot use it. Now, I could just get a BIOS image and exchange the device IDs there. But I wonder, wouldn't it be easier to just reactivate the PCIe slot through the OS? This e-mail is written through the ath wireless I got: # ifconfig ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290 ether 00:24:2c:1d:f0:2f media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ... wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:24:2c:1d:f0:2f inet 192.168.178.41 netmask 0xff00 broadcast 192.168.178.255 media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g status: associated ssid Obi-Wan Kenobi channel 7 (2442 MHz 11g) bssid 00:15:0c:d5:37:a0 regdomain 101 indoor ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit txpower 20 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL I achieved this by passing the BIOS check with the intel wireless and hot-swapping it with the atheros card afterwards. This is impractical and evil, so I'm still searching for a solution. But at least I know that the device works. HP laptops really dislike the fact that your card isn't part of the Centrino brand, so they halt if they find an Atheros. Your best option is to change the Atheros card EEPROM to match the device and vendor id of your wpi card. Then you also need to change the ath driver to attach to that device id. It's evil, but it's better than hot-swapping. Yes, but it still sucks. And I actually have no idea how to flash the ath device. All the instructions on this I have found use Linux. Please ask s...@freebsd.org about that. I'd prefer to flash the notebook BIOS, but I have no way to defeat its evil compression. I think flashing the bios is more risky than fixing the EEPROM. The other option is to buy a iwn card which works better in FreeBSD than wpi. Nay, this is my goodbye to Intel brand wireless. I always thought wpa_supplicant was to blame for unreliable connections, but it all just works with the Atheros hardware. Intel has made progress and I really think that they are on the right track to produce good cards. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? Use the link below to report this message as spam. https://lavabit.com/apps/teacher?sig=1117002key=1739816679 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Activate PCIe slot deactivated by BIOS
On 22 May 2010, at 13:27, Dominic Fandrey wrote: On 22/05/2010 13:47, Dominic Fandrey wrote: Today the card arrived and the BIOS complains (HP 6510b): 104-Unsupported wireless network device detected. System halted. Remove device and restart. The system boots if I turn off the wireless device in BIOS, but this means I cannot use it. Now, I could just get a BIOS image and exchange the device IDs there. But I wonder, wouldn't it be easier to just reactivate the PCIe slot through the OS? This e-mail is written through the ath wireless I got: # ifconfig ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290 ether 00:24:2c:1d:f0:2f media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ... wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:24:2c:1d:f0:2f inet 192.168.178.41 netmask 0xff00 broadcast 192.168.178.255 media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g status: associated ssid Obi-Wan Kenobi channel 7 (2442 MHz 11g) bssid 00:15:0c:d5:37:a0 regdomain 101 indoor ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit txpower 20 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL I achieved this by passing the BIOS check with the intel wireless and hot-swapping it with the atheros card afterwards. This is impractical and evil, so I'm still searching for a solution. But at least I know that the device works. HP laptops really dislike the fact that your card isn't part of the Centrino brand, so they halt if they find an Atheros. Your best option is to change the Atheros card EEPROM to match the device and vendor id of your wpi card. Then you also need to change the ath driver to attach to that device id. It's evil, but it's better than hot-swapping. The other option is to buy a iwn card which works better in FreeBSD than wpi. Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: disabling all serial input / output at boot time
On 15 Apr 2010, at 17:18, Julian Elischer wrote: On 4/15/10 3:03 AM, Mike Tancsa wrote: At 12:04 AM 4/15/2010, per...@pluto.rain.com wrote: Mike Tancsa m...@sentex.net wrote: I have an embedded device (Alix box) that is running RELENG_8 off a CF that is designed to monitor / control a serial sensor device. The sensor is quite chatty and is always outputing data at 115200. The problem is that this will interrupt the boot process. I even tried to fake it out, but trying to make com2, the console in /boot/device.hints ... Is there any way to completely disable serial interaction and to truly make the bootup process quiet and non interactive ? More of a workaround than a fix, but does it work any better if you connect the device to com2 instead of com1? Unfortunately there is only one serial port on the board we are using. yes but can the bios map it to be com2? If not, maybe there's some way to do this by changing the hints file. Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: disabling all serial input / output at boot time
On 15 Apr 2010, at 18:24, Mike Tancsa wrote: At 12:59 PM 4/15/2010, Rui Paulo wrote: If not, maybe there's some way to do this by changing the hints file. Prior to /boot/loader running, is that even consulted ? Right, I missed that... Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: NIC MAC problem
On 10 Apr 2010, at 15:01, Stanislav wrote: On fresh freebsd 8.0 one of my nics's mac addres is all zeroes. I can set it to the real manualy, but what may cause this. Is it hardware issue? It is ok on slackware linux. Please post your dmesg and detail which card model you have. Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: virtual machine on mac os x 10.6 to run FreeBSD ?
On 26 Mar 2010, at 13:41, Ross Nelson wrote: On Mar 26, 2010, at 8:25 AM, Dag-Erling Smørgrav wrote: Bob Bishop r...@gid.co.uk writes: Jiandong Lu lujiandong1...@yahoo.com.cn writes: hi,are there some virtual machines on mac os x 10.6 to run FreeBSD 8? FreeBSD 8.0 runs fine on 10.6 under Parallels 5, but that does cost money. Isn't there a free-as-in-beer edition of VMWare? VMware Server for Windows and Linux (as well as VMware Player on Windows) are both free as in beer, but there isn't a free VMware for Mac. VMware Fusion is $80USD and comparable to Parallels. I had the same problem with VirtualBox not working on OS X. FreeBSD, QNX, Plan 9, and Windows all failed when I tried to partition and format the virtual disk. I'll have to try the Enable IO APIC option to see if that works for me. Ross VirtualBox works fine last time I tried (last year) but you need to keep playing with the options to find a configuration that works. I was never able to use SCSI disks, for example. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ARM and structure size boundary
On 21 Jan 2010, at 10:21, Sebastian Huber wrote:
Hi,
on ARM the GCC has an option for the structure size boundary:
http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html#ARM-Options
In the GCC sources (gcc/config/arm) you see that NetBSD changes the default
value to 8 from 32.
For FreeBSD I did not found something similar. What value is used on FreeBSD
by default?
This value is (or was) important for the network stack. Do you know if the
current FreeBSD network stack is dependent on this value? In the file
gcc/config/arm/netbsd.h (GCC sources) is a comment about this topic.
Have a nice day!
Just for clarification, on FreeBSD, given it's use of the default structure
size boundary, if you composing a packet format using a structure, you need to
use __packed if the structure is not a multiple of 4.
struct a {
int8_t b;
int8_t b;
};
sizeof(struct a) on FreeBSD/arm is 4 and not 2. To make sure it will get the
correct value, you need to type:
struct a {
...
} __packed;
--
Rui Paulo
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [patch] add pwait utility
On 7 Nov 2009, at 07:02, Ulrich Spörlein wrote: I understand that shutdown duration is of zero importance for server operations, FWIW, I don't agree with this. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SB7xx watchdog: new driver for review and testing
On 18 Oct 2009, at 21:10, Andriy Gapon wrote: Please review and/or test a new driver for watchdog driver included into AMD SB7xx: http://people.freebsd.org/~avg/amdsbwd.tgz I have tested this driver only with SB700 on Gigabyte GA-MA780G-UD3H motherboard. ichwd driver was used as a starting point for this driver. This can be seen from some function names, general code organization and some small code snippets. Many thanks to ichwd authors and maintainers! Right now I have infrastructure only for building this driver as a module. Things for which that I need the most feedback/ideas: 1. If the driver actually works on your hardware and the hardware description. The driver can be tested by loading the driver and doing 'watchdog - t small number'. Having debug.bootverbose=1 may provide additional useful info. And better to test this from single-user mode with filesystems mounted r/o. 2. Better name for the driver. amdsbwd stands for AMD S(outh)B(ridge) WatchDog, but this abbreviation could be cryptic to decipher. 3. Proper location for this driver. At least on my system this driver needs resources (I/O ports and MEM range) that are claimed by ACPI, thus I've made it a child of acpi bus. But this driver doesn't have anything else ACPI-ish in it, so I decided that it doesn't belong under acpica/ or acpi_support/. Am I correct about this? Anything else you would like to report or comment or advise to me. Thank you very much for your help. The driver looks good in general. A few questions: - Can you make the magic numbers a define ? Where did they come from ? - Are you missing a device_set_desc() call ? - If this is what you want to commit, C++ comments are not allowed per- style Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SB7xx watchdog: new driver for review and testing
On 19 Oct 2009, at 16:41, Andriy Gapon wrote: I have put updated version of the driver (C file only) here: http://people.freebsd.org/~avg/amdsbwd.c Looks good to me. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: genuine cpu I386_CPU kernel support
On 22 Sep 2009, at 19:03, Nate Eldredge wrote: On Tue, 22 Sep 2009, John Baldwin wrote: My comment is to just use 4.x (seriously). A true 386 is going to be quite slow and the overhead of many things added that work well on newer processors is going to be very painful on a 386 (probably on a 486 as well). 4.x runs fine on a 386 and should support all the hardware you can stick into a machine with an 80386 CPU. Unless, of course, you plan to put it on a network. I doubt that 4.x is up to date with respect to security patches. I don't know if they were all applied on 4.x, but I think at least the older ones are. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: genuine cpu I386_CPU kernel support
On 23 Sep 2009, at 16:54, Julian H. Stacey wrote: 4.11 fell out of security support some while back, but http://www.freebsd.org/security/index.html only lists what's still in, not what fell out when. Right, but IIRC there were some folks patch 4-STABLE after the security officer dropped it. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
On Sun, Aug 23, 2009 at 06:38:12PM +0200, Marc Balmer wrote: Everyone should have the right to come back with a subject, if work is put into it. Or is the stanza that once there has been a heated discussion about a topic, there is no possibility to come back to it, maybe making it better a seccond time? And no, I have no plans to do so... I am just a bit astonished about the attitude... I think what Alexander was trying to say was that, given the heated discussion last time, people are now reluctant to restart another discussion. From what I remember, it was very hard to understand why such a large number of messages was being created for such a small detail. Topics, such as these, pose a high risk of making your FreeBSD developer experience more painful than it should be. And since I believe a lot of people here like to work on FreeBSD, sometimes these types of discussions are avoided for a long time just because the developer(s) doesn't(don't) want to make their FreeBSD development experience any more painful. I believe that if we keep insisting on the same bikesheds for a long time, developers will defintely go away. So, there's no ``stanza'' or whatever, just human nature. Regardless of what I just said, the topic keeps coming back and that's a clear sign that a framework should be developed and, possibly, in a way that appeals to both parties. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Reading acpi memory from a driver attached to hostb
On 18 Jul 2009, at 09:10, Andre Albsmeier wrote:
On Fri, 17-Jul-2009 at 12:53:53 -0700, Julian Elischer wrote:
Andre Albsmeier wrote:
[CC'ing this to Rui Paulo since he tried to help me a while ago]
Since my driver is a child of hostb0, I have no idea of how to
access
acpi0's memory area. Here is a devinfo -r to make things clear:
...
Earlier, I was given the hint to attach as a child of acpi (see the
old mail attached below) but in this case I didn't have access to
the
hostb registers which I need as well.
The only thing I see is: Attach two drivers -- one as child of acpi
and another as child of hostb and let them communicate somehow (no
idea how to do this).
I have also done crazy things like searching for acpi0 and trying
to bus_alloc_resource() the memory I am interested in but this also
failed.
Or is it possible to free(!) somehow the address space from acpi0
and pass it to hostb0 so I can bus_alloc_resource() it?
You can probably make two drivers in one which cooperate to
allow access to both sets of resources.
Hmm, that's what I meant by: Attach two drivers -- one as child of
acpi
and another as child of hostb...
And that's similar to Rui Paulo's suggestion a while ago:
You'll probably need to create a fake ACPI child driver to access it.
Create your identify routine with something like:
static void mydriver_identify(driver_t *driver, device_t parent)
{
if (device_find_child(parent, mydriver, -1) == NULL
mydriver_match(parent))
device_add_child(parent, mydriver, -1);
}
mydriver_match() should check if you were given the acpi0 device.
But in order to attach to acpi0, I need to say
DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL,
NULL );
instead of
DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL,
NULL );
This way I could attach to acpi but not to hostb anymore
I have searched the net for solutions, I have read newbus-draft.txt
and newbus-intro.txt and Warner Losh's newbus-led.c (thanks to all
of these my driver is working on other mainboards where it doesn't
have to access foreign memory) but didn't find anything.
I'm out of ideas.
John, do you know if this is a newbus limitation or if it can be
worked around ?
--
Rui Paulo
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: 7.2-PRERELEASE hangs every time after running airodump-ng on ath0 for a few hours
On 11 Jun 2009, at 02:43, Yuri wrote: Quoting Glen Barber glen.j.bar...@gmail.com: By chance, are you running an out-of-sync kernel / userland? You say the kernel is from May 6, and in the subject is 7.2-PRERELEASE. 7.2 was -RELEASEd on May 3. I just updated to more recent 72-STABLE and still got the hang. It would help if you could provide the backtrace. http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html Also, you may want to try HEAD because monitor mode has changed quite a bit in HEAD. Regards, -- Rui Paulo PGP.sig Description: This is a digitally signed message part
Re: MosChip 7840 dual port ucom
On 26 May 2009, at 16:23, Dmitry Morozovsky wrote: Dear colleagues, any hints/directions to get MosChip 7840 dual port USB to RS232 adapter working? In usbdevs output the device is shown as port 1 addr 2: high speed, power 100 mA, config 1, product 0x7840(0x7840), vendor 0x9710(0x9710), rev 0.01 Thanks in advance. I believe this isn't supported under FreeBSD. The Linux driver is mos7840.c. Might not be very hard to do a FreeBSD driver. Regards, -- Rui Paulo -- Rui Paulo PGP.sig Description: This is a digitally signed message part
Re: writing libnetstat for Summer of Code 2009
On 16 Mar 2009, at 14:16, Cipta H wrote: 2. How much experience in C do you need to do this project? Do you need to know the FreeBSD kernel? Yes, you need to understand the C programming language well and to be able to learn how the FreeBSD kernel works. You also need to figure out a way to structure the data. I know that XML was proposed in the past, but I don't know if this is the case. -- Rui Paulo PGP.sig Description: This is a digitally signed message part
Re: writing libnetstat for Summer of Code 2009
On 16 Mar 2009, at 19:04, Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Cipta, Cipta H wrote: XML? I was thinking of some opaque C structures that the functions write data to, and then supply some accessor methods, just like the ones in libmemstat. Or are you thinking of a different XML? I'm not very sure but I think Rui is referring XML like the GEOM subsystem has used (perhaps to have the kernel expose the statistics data with XML and the userland part of the library parse and return the result)? That's it. Of course, Robert should now more about this than I do and since he mentioned libmemstat, opaque C structs are probably what he was thinking. -- Rui Paulo PGP.sig Description: This is a digitally signed message part
Re: INTR_FILTER?
On 2 Feb 2009, at 11:38, Andriy Gapon wrote: on 30/01/2009 00:30 Rui Paulo said the following: On 29 Jan 2009, at 17:51, Andriy Gapon wrote: BTW, INTR_FILTER seems quite useful. Why, then, it is not the default? The drivers would have to be ported to INTR_FILTER. Right now, only asmc is using INTR_FILTER, so I don't think there is much gain in making it the default. I am not sure about this part. From the code it seems that INTR_FILTER is backward-compatible, i.e. it gives something and doesn't take away anything. The API and conventions seems to be the same too. There could be some edge cases, of course. Ok, but why enable it in GENERIC right now if the only driver that uses INTR_FILTER is asmc? There's not much point in enabling it now. Maybe in the future. Regards, -- Rui Paulo PGP.sig Description: This is a digitally signed message part
Re: INTR_FILTER?
On 2 Feb 2009, at 12:01, Andriy Gapon wrote: on 02/02/2009 13:53 Rui Paulo said the following: On 2 Feb 2009, at 11:38, Andriy Gapon wrote: on 30/01/2009 00:30 Rui Paulo said the following: On 29 Jan 2009, at 17:51, Andriy Gapon wrote: BTW, INTR_FILTER seems quite useful. Why, then, it is not the default? The drivers would have to be ported to INTR_FILTER. Right now, only asmc is using INTR_FILTER, so I don't think there is much gain in making it the default. I am not sure about this part. From the code it seems that INTR_FILTER is backward-compatible, i.e. it gives something and doesn't take away anything. The API and conventions seems to be the same too. There could be some edge cases, of course. Ok, but why enable it in GENERIC right now if the only driver that uses INTR_FILTER is asmc? There's not much point in enabling it now. Maybe in the future. I may be wrong but this could auto-magically improve some cases where there are shared interrupts between drivers with ithreads. In this case, I think, their interrupt handler would be run in parallel instead of sequentially. I haven't read the details of the implementation yet, but how does that work? Also, it would make it easier to write new drivers - one would not have to code for !INTR_FILTER case. Yes, but essentially, backporting needs the !INTR_FILTER case. And I don't know about !i386 !amd64 archs. -- Rui Paulo PGP.sig Description: This is a digitally signed message part
Re: Mackbook pro nvidia based video backlight
On 30 Jan 2009, at 07:52, Alexander Leidinger wrote: Quoting Ed Schouten e...@80386.nl (from Thu, 29 Jan 2009 15:36:06 +0100): * Alexander Leidinger alexan...@leidinger.net wrote: So you want that either - a daemon running as root is written which listens to user requests to set the backlight via sysctl or - a SUID root program is written that sets the backlight via sysctl instead of - a character device with appropriate filesystem permissions which allows to not go the SUID root or daemon running as root way ? Yes. The primary reason is that it is more consistent with the rest of the operating system. powerd also uses sysctl's instead of a character device, for example. Powerd does not interact with the user, it is doing automatic power management. A backlight on the other hand needs to be adjustable by the user. Normally I would expect some keys on the keyboard to handle this, so there should be no need to have some userland stuff, but as I don't know about how Apple is doing this, I assume there's some valid reason to handle it from userland. But then there needs to be some easy way to let an user handle it, even if you are on the console. A separate daemon or a SUID root program to control the backlight sounds like overkill to me. Well, easy: only let the operator group change the sysctl and add your appropriate user accounts to the operator group. No daemon is needed. This is what I thought about when doing the Intel backlight driver, but I never actually did it. Regards, -- Rui Paulo PGP.sig Description: This is a digitally signed message part
Re: Mackbook pro nvidia based video backlight
On 30 Jan 2009, at 07:52, Alexander Leidinger wrote: Quoting Ed Schouten e...@80386.nl (from Thu, 29 Jan 2009 15:36:06 +0100): * Alexander Leidinger alexan...@leidinger.net wrote: So you want that either - a daemon running as root is written which listens to user requests to set the backlight via sysctl or - a SUID root program is written that sets the backlight via sysctl instead of - a character device with appropriate filesystem permissions which allows to not go the SUID root or daemon running as root way ? Yes. The primary reason is that it is more consistent with the rest of the operating system. powerd also uses sysctl's instead of a character device, for example. Powerd does not interact with the user, it is doing automatic power management. A backlight on the other hand needs to be adjustable by the user. Normally I would expect some keys on the keyboard to handle this, so there should be no need to have some userland stuff, but as I don't know about how Apple is doing this, I assume there's some valid reason to handle it from userland. But then there needs to be some easy way to let an user handle it, even if you are on the console. A separate daemon or a SUID root program to control the backlight sounds like overkill to me. Well, easy: only let the operator group change the sysctl and add your appropriate user accounts to the operator group. No daemon is needed. This is what I thought about when doing the Intel backlight driver, but I never actually did it. Regards, -- Rui Paulo PGP.sig Description: This is a digitally signed message part
Re: INTR_FILTER?
On 29 Jan 2009, at 11:47, Andriy Gapon wrote: INTR_FILTER - what does it do? It doesn't seem to be documented anywhere, but seems to affect interrupt code. INTR_FILTER allows you to skip the FILTER+ITHREAD headache. See dev/asmc/asmc.c for an example. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: INTR_FILTER?
On 29 Jan 2009, at 11:47, Andriy Gapon wrote: INTR_FILTER - what does it do? It doesn't seem to be documented anywhere, but seems to affect interrupt code. INTR_FILTER allows you to skip the FILTER+ITHREAD headache. See dev/asmc/asmc.c for an example. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: INTR_FILTER?
On 29 Jan 2009, at 17:51, Andriy Gapon wrote: on 29/01/2009 19:17 Rui Paulo said the following: On 29 Jan 2009, at 11:47, Andriy Gapon wrote: INTR_FILTER - what does it do? It doesn't seem to be documented anywhere, but seems to affect interrupt code. INTR_FILTER allows you to skip the FILTER+ITHREAD headache. Could you please explain a little bit what is this headache? Basically, you use filter + ithread (intr_filter) when you want to do more than basic things in your interrupt handler routine. For example, allocating memory must be done in a ithread, it can't be done on the interrupt routine. I thought, similarly to what Ed said, that in filter one could quickly check for a stray interrupt (or shared interrupt from other device) and in ithread one could perform meaningful work. That's right. But INTR_FILTER does all the filter + ithread setup for you via FILTER_SCHEDULE_THREAD. But I also had some doubts about what is legal and what is illegal in ithread. E.g. could I take a non-spin mutex or wait on a condvar? I guess not - because in the case of shared interrupts the same ithread is used to handle everything. See dev/asmc/asmc.c for an example. Thank you, the example is enlightening. But also one has to look into how the framework works (or just know it) to understand why things are done this way but not the other. E.g. why you have to use a taskqueue in non-INTR_FILTER case. I needed a taskqueue because devctl_notify() calls malloc and you can't call malloc (which holds some type of lock, I can't remember) from an interrupt context (asmc_sms_intrfast()) BTW, INTR_FILTER seems quite useful. Why, then, it is not the default? The drivers would have to be ported to INTR_FILTER. Right now, only asmc is using INTR_FILTER, so I don't think there is much gain in making it the default. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Mackbook pro nvidia based video backlight
On 28 Jan 2009, at 13:43, Ed Schouten wrote: * Daniel Lannstrom o...@trekdanne.se wrote: I'm asking which method will be the best to interface the driver with userland applications? You might want to make it a character device driver. And write a small userland control program. Sysctl isn't really made for this kind of functionality. No. sysctl is good for doing stuff like this. An even better approach would be to integrate it to the X11 driver, but I guess it will be cold day in hell when this happens. Not really. The xorg intel driver is already able to deal with this. I don't know about NVIDIA. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Mackbook pro nvidia based video backlight
On 28 Jan 2009, at 13:43, Ed Schouten wrote: * Daniel Lannstrom o...@trekdanne.se wrote: I'm asking which method will be the best to interface the driver with userland applications? You might want to make it a character device driver. And write a small userland control program. Sysctl isn't really made for this kind of functionality. No. sysctl is good for doing stuff like this. An even better approach would be to integrate it to the X11 driver, but I guess it will be cold day in hell when this happens. Not really. The xorg intel driver is already able to deal with this. I don't know about NVIDIA. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Mackbook pro nvidia based video backlight
On 27 Jan 2009, at 15:00, Daniel Lannstrom wrote: I'm asking which method will be the best to interface the driver with userland applications? You might want to make it a character device driver. And write a small userland control program. Sysctl isn't really made for this kind of functionality. Why not? Sysctl seems perfect to handle this. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Writing device drivers: How to access a specific memory area?
On 25 Dec 2008, at 09:53, Andre Albsmeier wrote:
Hello all,
I am writing a driver which needs to access memory at a
specific location. The location depends on what the BIOS
has configured into the host bridge. For example, my
current machine uses an Intel 975X chipset and the memory
location I am interested in has been set to 0xFED14000 and
is 16KB in size (this is MCHBAR of the 975X memory hub).
You probably just need to do something like:
rid = PCI_BAR(number);
res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, rid, RF_ACTIVE);
And then,
bus_read_4(res, offset from specified PCI BAR);
I have no idea how to access this space from my driver.
I have played around with bus_alloc_resource() but this
only gives me back NULL.
However, a devinfo -r gives me:
nexus0
npx0
acpi0
Interrupt request lines:
9
I/O ports:
0x10-0x1f
...
0x800-0x87f
I/O memory addresses:
0x0-0x9
0xc-0xd
0xe-0xf
0x10-0x7fff
0xf000-0xf3ff
0xfec0-0xfec00fff
0xfed13000-0xfed19fff ---
0xfed1c000-0xfed1
0xfed2-0xfed3
0xfed5-0xfed8
0xfee0-0xfee00fff
0xffb0-0xffbf
0xfff0-0x
cpu0
...
The line marked with --- shows the range which includes
the location I am interested in. It is probably assigned
to the acpi0 device.
How do I proceed from this? Do I have to hack around in
the ACPI-Code? I don't hope so ;-)
You'll probably need to create a fake ACPI child driver to access it.
Create your identify routine with something like:
static void mydriver_identify(driver_t *driver, device_t parent)
{
if (device_find_child(parent, mydriver, -1) == NULL
mydriver_match(parent))
device_add_child(parent, mydriver, -1);
}
mydriver_match() should check if you were given the acpi0 device.
I only need access to this memory location during the
probe of my driver to read some configuration data.
Is this pci configuration space ? If so, pci_read_config (man 9 pci)
should be just what you need.
Regards,
--
Rui Paulo
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD development
On 2 Nov 2008, at 10:11, Tapac Khoma wrote: Hello! I use FreeBSD 6.1 as my desktop system. I like it very much. But there are some features I want my system have. I began to investigate of kernel structure and tried to write some devices drivers. So I want to know can I help for you in development of my favor system. And where I can find useful information about writing device drivers under FreeBSD. Some pointers: http://www.freebsd.org/projects/index.html http://www.freebsd.org/doc/en/books/developers-handbook/ http://www.freebsd.org/doc/en/books/arch-handbook/ Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: svn rev. number
On 1 Oct 2008, at 13:04, Danny Braniss wrote: Hi, Now that freebsd is under svn, I decided to try what I failed with cvs, and actually using svn/svk/svnsync I have a mirror and a local branch in sync! Since the date reported by uname is not that relevant, is it possible to add the svn-revision # ala build-...? This could make finding problems easier, instead of kernel from 'date' one could say date/revision... just a thought. That was already done weeks ago: [EMAIL PROTECTED] ~ % uname -v FreeBSD 8.0-CURRENT #2 r182964: Sat Sep 13 17:32:57 WEST 2008 [EMAIL PROTECTED] :/home/rpaulo/freebsd/obj/home/rpaulo/freebsd/base/head/sys/ALPHA `ident /boot/kernel/kernel' also works. Regards, -- Rui Paulo -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Creation of the NO_SSP build knob
On Thu, Sep 04, 2008 at 02:46:53PM +0200, Jeremie Le Hen wrote: Hello, There is currently a knob to enable/disable SSP: WITH_SSP or WITHOUT_SSP. WITH_SSP is the default on -CURRENT, so no one had to put WITH_SSP= in src.conf(5). This has hidden the following bug so far: When buildworld is run with WITH_SSP= on command-line or in src.conf(5), it fails immediately with the following message, because the toolchain is built with WITHOUT_SSP: % /usr/src/share/mk/bsd.own.mk, line 365: WITH_SSP and WITHOUT_SSP can't both be set. My leaning is to create an additional knob NO_SSP, much like NO_CPU_CFLAGS, that could be set internally. However I'm not sure it complies with the src.conf(5) policy. Any objection to the patch below? We already have something like that. WITHOUT_SENDMAIL= is expanded to MK_SENDMAIL=no. You may want to do the same for SSP and keep the convention of the variable names. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: killing a kthread
On Wed, Sep 03, 2008 at 09:34:47AM +0100, kr Lekha wrote:
Hi,
i wanted to kill a kthread created by my module, There is no actual
kthread_kill to kill it
hence I tried to send kill signal to thread
psignal(p, SIGTERM);
psignal(p, SIGKILL);
killproc(p,messeage);
and kthread_suspend()
Nothing seems to be killing the kthread, I still see it
[root@ /usr/src]# ps awx -l | grep kernel
UID PIDPPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND
0 1048 1 0 20 0 0 8 ktsusp DL
?? 0:00.01 [new_kernel_thread]
I have noticed that generally if kernel module wanted to kill a thread then
it calls
{
wakeup(p);
msleep(p,0); /*or tsleep*/
}
This puts the thread to sleep forever. However kthread_suspend also performs
same actions.
Does scheduler take care to killing it?
I read that after 2 min scheduler wakes up the thread and
eventually kills it,
i see the same kthread suspended even after a day
I would appreciate any thoughts in this reagard.
Thanks,
When the thread finishes what it's doing, it should call kthread_exit().
Regards,
--
Rui Paulo
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tilt/horizontal scroll support
On Wed, Aug 13, 2008 at 06:41:45PM +0300, Andriy Gapon wrote: I have the following mouse: http://www.logitech.com/index.cfm/partners/system_builders_integrators/products/mice/devices/3141cl=gb,en# ... So now I have two questions. 1. What would be the best way to each ums about the tilt capability of this mouse? Is there some generic way to detect it or maybe logitech-specific way or some model-specific quirk is required? 2. What would be the best way to pass tilting data to consumers? I see two possibilities: A) map data[4] to some extended button value (do it in ums driver), e.g. to button 6 and button 7; B) it seems that dz value is always 1 or -1, amount of scrolling affects number of mouse events, but abs(dz) is always 1; if this is really always true, then tilting could be piggy-backed onto dz as +2/-2 value (or some such) and then Xorg sysmouse driver could be taught to interpret such values as special button presses (similarly to how vertical scrolling is handled in it). Well, perhaps the best way is to teach sysmouse about horizontal scrolling and then add a quirk WRT your mouse ? sysmouse(4) really needs to grow horizontal scrolling since nowadays every mouse has it. Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Suggestion for 'pkg_add -r'
On 7 Aug 2008, at 11:53, Anders Nore wrote: Hi, In my pkg_improved GSoC project I've added a nice feature for 'pkg_add -r' which displays the size of the file being downloaded as well as progress status in % and bytes/kb/mb/... and download speed. If someone could test it and comment it would be perfect, below you can find the patches for RELENG_7 and -CURRENT. (As for now pkg_add does not have a -q/Q option (quiet), but this could perhaps be used to deprecate the output?). RELENG_7: http://home.no.net/andenore/patches/pkg_install_2008-08-06_RELENG_7.diff CURRENT: http://home.no.net/andenore/patches/ pkg_install_2008-08-06_CURRENT.diff Some comments: * I think you have reversed the patch. :-) * Build errors: cc1: warnings being treated as errors file.c:433: warning: no previous prototype for 'power' file.c:452: warning: no previous prototype for 'human_readable' file.c:474: warning: no previous prototype for 'printHumanReadable' file.c: In function 'printHumanReadable': file.c:482: warning: comparison between signed and unsigned parallels# ./pkg_add -r joe Fetching 321.2 kB from ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-current/Latest/joe.tbz ... Downloading: 100% 321.2 kB at 214.8 kB/ s Done Fetching 2.4 MB from ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-current/All/gettext-0.17_1.tbz ... Done Fetching 2.2 MB from ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-current/All/aspell-0.60.6_2.tbz ... Downloading: 201%4.5 MB at 149.5 kB/s Something's wrong :-) Also, may I suggest that you make your output similar to fetch(1) ? Keep up the good work, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AuthenticAMD, cpufreq and SunFire X2200
On Fri, Jul 11, 2008 at 11:05:36PM +0300, Danny Braniss wrote: no AMD datasheets, but here goes acpidump: I think we need more than the dump of the tables. Try acpidump -dt. Unfortunately, I can't really help you because I know nothing about PowerNow and I have no available time at the moment to dig that up. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: eeePC 900 turning off wireless (ath0)
On Mon, Jul 07, 2008 at 02:19:37PM +0200, Matthias Apitz wrote: /* Notify devd(8) */ device_printf(sc-dev, Fn+F2 pressed, notify to devd(8) is %08x\n, notify); acpi_UserNotify(ASUS-Eee, h, notify); and it turns out that in case of switching wireless of it is 0x0011, while on switch-on it is 0x0010; but the devd(8) only sees both events as '_SB_.ATKD'; I've grep'ed a lot around but can't see the place where the hex events of acpi_UserNotify() are converted into the string '_SB_.ATKD', any idea where to look; They are not converted, your devd.conf entries are probably wrong. Can you show again where do you get _SB_.ATKD from? -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: eeePC 900 turning off wireless (ath0)
On Fri, Jul 04, 2008 at 04:40:02PM +0200, Matthias Apitz wrote: El día Tuesday, July 01, 2008 a las 12:14:26PM +0100, Rui Paulo escribió: On Tue, Jul 01, 2008 at 11:02:20AM +0200, Matthias Apitz wrote: Rui, Have you commited your changes to RELENG_7 too or only to HEAD? I'm asking because Fn+F2 does toggle the power of the wireless NIC but devd(8) does not see any ACPI event in this case; it sees it for example if the battery comes full; thx for clarifying this could you please send me the /etc/devd.conf file you mention in the page http://wiki.freebsd.org/AsusEee ? in the one which came out of CVS with RELENG_7 I could not see anything about hotkeys; thx in advance Only to HEAD. I'm going to MFC it today. Hello Rui, With your changes of acpi_asus.c in RELENG_7 the devd(8) and my hook-script in /usr/local/etc/devd/ath.conf sees the Fn+F2 now as the event ACPI ASUS-Eee _SB_.ATKD, but it is anyway if Fn+F2 switches off or on the wireless NIC, the event for devd(8) is always the same; from the above event it is clear where the strings for system ACPI and subsystem ASUS-Eee come from, but I don't see where the string _SB_.ATKD is made; it must be derived from the 'notify' argument of the call /* Notify devd(8) */ acpi_UserNotify(ASUS-Eee, h, notify); and I was hoping to distinguish it into two different events, one when Fn+F2 is switching off the NIC, and one of the case of switch on; any idea? thx If you get the same string from the event, there's not much we can do. _SB_.ATKD is the ACPI namespace for the keyboard. Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Custom VESA modes on FreeBSD 7?
On Sat, Jun 28, 2008 at 07:15:33PM -0400, Mike Meyer wrote: I'm trying to get FreeBSD 7-RELEASE running in a VirtualBox VM to use all of my LCD panel in X. The running X is using the vesa driver, which should be cool for this, as VirtualBox has provisions for creating custom vesa modes. And in fact, the Xorg.0.log file shows that it sees the new mode - but it doesn't use it. The VirtualBox docs note that for Linux to use such a mode, you have to provide a vga command line option with the new mode # in it to the linux kernel. None of the FreeBSD boot parameters seem applicable here. Basically, the question is - what do I have to do to get the X.org vesa driver to use a non-standard vesa mode on FreeBSD? Is there any other information I can attach that might help with this? Maybe you need to add a correct ModeLine to your xorg config file ? A quick Google search returned: http://forums.virtualbox.org/viewtopic.php?t=59 HTH, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: eeePC 900 turning off wireless (ath0)
On Tue, Jul 01, 2008 at 11:02:20AM +0200, Matthias Apitz wrote: Rui, Have you commited your changes to RELENG_7 too or only to HEAD? I'm asking because Fn+F2 does toggle the power of the wireless NIC but devd(8) does not see any ACPI event in this case; it sees it for example if the battery comes full; thx for clarifying this could you please send me the /etc/devd.conf file you mention in the page http://wiki.freebsd.org/AsusEee ? in the one which came out of CVS with RELENG_7 I could not see anything about hotkeys; thx in advance Only to HEAD. I'm going to MFC it today. Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: eeePC 900 turning off wireless (ath0)
On Sun, Jun 29, 2008 at 06:05:27PM +0200, Matthias Apitz wrote: Hola Rui, I've found your very usefull pages in http://wiki.freebsd.org/AsusEee I CVS'uped the kernel to RELENG_7, built it and moved it to the eeePC; now Fn+F2 works as it should and I can even kldunload if_ath, power-off and power-on the wireless card, and after kldload if_ath the interface comes up fine again and my devd(8) hook assigns IP again; now it works as it should; will have a look into the events seen by devd(8) to make the kldunload and kldload perhaps there; thanks for your work and help; Cool, no problem. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: eeePC 900 turning off wireless (ath0)
On Fri, Jun 27, 2008 at 10:02:03AM +0200, Matthias Apitz wrote: Hello Rui, I recompiled the kernel to have if_ath out of the kernel, but as a loaded module at boot: $ kldstat Id Refs AddressSize Name 1 14 0xc040 8c7098 kernel 21 0xc0cc8000 1242cif_ath.ko 33 0xc0cdb000 46324ath_hal.ko 42 0xc0d22000 4218 ath_rate.ko 51 0xc0d27000 14324snd_hda.ko 62 0xc0d3c000 4a5acsound.ko 71 0xc0d87000 6a32cacpi.ko 81 0xc4394000 22000linux.ko I can unload if_ath, ath_hal and ath_rate which drops the interface ath0, but even in this case Fn+F2 has no affect at all; any idea? Oh, then I guess the 900 is different. I've had a look into the Xandros Linux and they do it with ACPI events, dropping the modules and others; I could provide their script /etc/acpi/wlan.sh if someone wants to have a look into; If turning off WLAN is now done via ACPI events, then the patch I committed to HEAD will probably help. I'll MFC it in a week, but if you can give it a try, that would be great. Please contact me off-list if you need assistance. Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: eeePC 900 turning off wireless (ath0)
On Thu, Jun 26, 2008 at 09:55:45AM +0200, Matthias Apitz wrote: Hello, Yesterday I did some tests with my eeePC 900 to see how long it would work with the 4400 mAh battery ... it seems that turning of the wireless card (ath0), which can be turned of from the BIOS, has big effect and let work the eeePC for more then 2hours 15minutes; in the Xandros Linux you can turn off the NIC as well with Fn+F2 which in FreeBSD does not work at boot stage, i.e. when you may defer the booting in the boot loader countdown; Yes, this only works after booting. At least on the 701. is there any way to switch this off without going into the BIOS? After booting you can unload ath module and press Fn+F2. It should turn off wireless. The problem is that you can't turn it back on. For that, we need PCIe hotplug support. (That's what Fn+F2 does, it ejects the wireless card). Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mplayer pauses when holding a window
On Thu, Jun 05, 2008 at 09:49:12AM +0200, Harald Servat wrote: Hello, today I was running mplayer playing an streaming url (just audio). There was a moment that I holded a(ny) window (i.e., click to move) for a long time (about 10-15s) and mplayer paused. Have anyone experienced this issue? I'm running mplayer-0.99.11_4 (I configured it to use esound), gnome2-lite-2.22.0, xorg 7.3 on FreeBSD 7.0 (ULE)/ia32. This is normal behavior and I think this is a Window Manager issue, not a FreeBSD issue. Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rdmsr from userspace
Kostik Belousov wrote: On Sat, May 17, 2008 at 06:26:01PM +0100, Rui Paulo wrote: Andriy Gapon wrote: on 17/05/2008 18:37 Rui Paulo said the following: Andriy Gapon wrote: It seems that rdmsr instruction can be executed only at the highest privilege level and thus is not permitted from userland. Maybe we should provide something like Linux /dev/cpu/msr? I don't like interface of that device, I think that ioctl approach would be preferable in this case. Something like create /dev/cpuN and allow some ioctls on it: ioctl(cpu_fd, CPU_RDMSR, arg). What do you think? While I think this (devcpu) is good for testing and development, I prefer having a device driver to handle that specific MSR than a generic /dev/cpuN where you can issue MSRs. Both for security and reliability reasons. What about /dev/pci, /dev/io? Aren't they a precedent? They are, but, IMHO, we should no longer continue to create this type of interfaces. Why ? Are developers some kind of the second-class users ? I would have no opinion on providing /dev/cpu by the loadable module, not compiled into GENERIC. But the interface itself is useful at least for three things: - CPU identification (see x86info or whatever it is called); - CPU tweaking for bugs workaround without patching the kernel; - updating the CPU microcode. None of these is limited to the developers only. Input validation is my main concern here. Regarding to your two last points, I would prefer to have a microcode driver than a microcode userland utility that relies on devcpu. Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rdmsr from userspace
Mike Meyer wrote: On Sat, 17 May 2008 11:13:52 +0300 Andriy Gapon [EMAIL PROTECTED] wrote: It seems that rdmsr instruction can be executed only at the highest privilege level and thus is not permitted from userland. Maybe we should provide something like Linux /dev/cpu/msr? I don't like interface of that device, I think that ioctl approach would be preferable in this case. Something like create /dev/cpuN and allow some ioctls on it: ioctl(cpu_fd, CPU_RDMSR, arg). What do you think? Ok, this points directly at a question I've been wondering about, but haven't been able to find an answer in the google. I've been mucking about with general access to sysctl's (a sysctl plugin for gkrellm, and a python module for accessing sysctls), and with that hammer in my hand, the nail for this problem is obviously a dev.cpu.#.msr sysctl. How can you request a rdmsr within the sysctl tree? I don't think sysctl is appropriate here either. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rdmsr from userspace
Kostik Belousov wrote: On Sun, May 18, 2008 at 04:47:41PM +0100, Rui Paulo wrote: Kostik Belousov wrote: On Sat, May 17, 2008 at 06:26:01PM +0100, Rui Paulo wrote: Andriy Gapon wrote: on 17/05/2008 18:37 Rui Paulo said the following: Andriy Gapon wrote: It seems that rdmsr instruction can be executed only at the highest privilege level and thus is not permitted from userland. Maybe we should provide something like Linux /dev/cpu/msr? I don't like interface of that device, I think that ioctl approach would be preferable in this case. Something like create /dev/cpuN and allow some ioctls on it: ioctl(cpu_fd, CPU_RDMSR, arg). What do you think? While I think this (devcpu) is good for testing and development, I prefer having a device driver to handle that specific MSR than a generic /dev/cpuN where you can issue MSRs. Both for security and reliability reasons. What about /dev/pci, /dev/io? Aren't they a precedent? They are, but, IMHO, we should no longer continue to create this type of interfaces. Why ? Are developers some kind of the second-class users ? I would have no opinion on providing /dev/cpu by the loadable module, not compiled into GENERIC. But the interface itself is useful at least for three things: - CPU identification (see x86info or whatever it is called); - CPU tweaking for bugs workaround without patching the kernel; - updating the CPU microcode. None of these is limited to the developers only. Input validation is my main concern here. Regarding to your two last points, I would prefer to have a microcode driver than a microcode userland utility that relies on devcpu. Did you looked at the code ? It does exactly what you described. Driver has four basic operations: read/write msr perform cpu id work update microcode. The later is done as a whole operation, with the microcode blob supplied by the userspace. Yes, but I still don't like having everything mixed up in one driver. At the very least, I would like us to have two drivers. One for the microcode update and the other driver for the rest. I would like to see a microcode update utility (driver + something to parse Intel's file aka devcpu-data) in the base system, but not the rest, though. Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rdmsr from userspace
Mike Meyer wrote: On Sun, 18 May 2008 16:50:28 +0100 Rui Paulo [EMAIL PROTECTED] wrote: Mike Meyer wrote: On Sat, 17 May 2008 11:13:52 +0300 Andriy Gapon [EMAIL PROTECTED] wrote: It seems that rdmsr instruction can be executed only at the highest privilege level and thus is not permitted from userland. Maybe we should provide something like Linux /dev/cpu/msr? I don't like interface of that device, I think that ioctl approach would be preferable in this case. Something like create /dev/cpuN and allow some ioctls on it: ioctl(cpu_fd, CPU_RDMSR, arg). What do you think? Ok, this points directly at a question I've been wondering about, but haven't been able to find an answer in the google. I've been mucking about with general access to sysctl's (a sysctl plugin for gkrellm, and a python module for accessing sysctls), and with that hammer in my hand, the nail for this problem is obviously a dev.cpu.#.msr sysctl. How can you request a rdmsr within the sysctl tree? I don't think sysctl is appropriate here either. Reading (or writing) a sysctl mib can trigger a sysctl handler, which can do pretty much anything. In particular, there are already examples in the kernel where sysctl handlers use devices that don't have /dev entries to get set their values. Look through kern/kern_cpu.c and i386/cpufreq/p4tcc.c to see the two ends of that kind of connection. In fact, the cpu frequency sysctls would seem to be an excellent model for something like the msr. ioctl, open+read/write, sysctl - they're all just interfaces to kernel handlers. mike Yes, sure, but who do you select the MSR you want to read or write? dev.cpu.N.insert MSR number in hexadecimal here ? I'll have to think about whether or not I like this interface. Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rdmsr from userspace
Mike Meyer wrote: I don't think that would work - you'd have to register all those hexadecimal strings as sysctl names. Yes, in theory you could also hack sysctl in a way that it doesn't walk when you do a sysctl -a, but works fine when you issue sysctl dev.cpu.N.0xffaabbcc, for example. I would be against this, though, because this will be like sysctl on steroids, a really crude hack. You could do an interface like this, but the calling program would have to use sysctlnametomib to get dev.cpu.N.msr, then append the MSR number to the results. Not really very pretty. If you want to allow the user to poke at arbitrary msrs, this would be a way to do it with sysctls, but the file api is probably better. Agreed. On the other hand, if you want to allow access to the fixed set of documented msr's (for each cpu model, anyway), then handing back that fixed set as an array would be a better approach, and would have the advantage of not having to deal with invalid requests (non-existent MSRs, 1-byte reads/writes of multi-byte MSRs, etc). On the other hand, it might be more useful - *especially* if the MSRs move around depending on processor types (I honestly don't know) They do. At least on Intel (I don't know about AMD). But this moving is not documented. - to provide a named interface: dev.cpu.0.msr.mtrr dev.cpu.0.msr.arr dev.cpu.0.msr.efer and so on. You'd register the names when the module was initialized, and would only register the ones that actually existed. You'd then never have to deal with a request for a non-existent MSR, because the sysctl call would return an error to the calling program without ever calling your handler. Of course, you can *combine* these two approaches, and have: dev.cpu.0.msr.all# returns an array of all available msrs dev.cpu.0.msr.have # an array of the available msrs but at this point it's just blue sky speculation... I'll have to think about whether or not I like this interface. Actually, I'm more interested in why there seems to be a dislike of file-based interfaces in favor of sysctls in the freebsd community. Speaking for myself, sometimes sysctl is an interface that just works and is simple enough. Of course there are some types of structured data that don't belong to sysctl, but overall, I don't think we are abusing it. Creating a /dev node, handling ioctl's, etc. is much more work and error prone. That's all. At least for me. Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rdmsr from userspace
Andriy Gapon wrote: It seems that rdmsr instruction can be executed only at the highest privilege level and thus is not permitted from userland. Maybe we should provide something like Linux /dev/cpu/msr? I don't like interface of that device, I think that ioctl approach would be preferable in this case. Something like create /dev/cpuN and allow some ioctls on it: ioctl(cpu_fd, CPU_RDMSR, arg). What do you think? While I think this (devcpu) is good for testing and development, I prefer having a device driver to handle that specific MSR than a generic /dev/cpuN where you can issue MSRs. Both for security and reliability reasons. Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rdmsr from userspace
Andriy Gapon wrote: on 17/05/2008 18:37 Rui Paulo said the following: Andriy Gapon wrote: It seems that rdmsr instruction can be executed only at the highest privilege level and thus is not permitted from userland. Maybe we should provide something like Linux /dev/cpu/msr? I don't like interface of that device, I think that ioctl approach would be preferable in this case. Something like create /dev/cpuN and allow some ioctls on it: ioctl(cpu_fd, CPU_RDMSR, arg). What do you think? While I think this (devcpu) is good for testing and development, I prefer having a device driver to handle that specific MSR than a generic /dev/cpuN where you can issue MSRs. Both for security and reliability reasons. What about /dev/pci, /dev/io? Aren't they a precedent? They are, but, IMHO, we should no longer continue to create this type of interfaces. Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD OS Detection and Uptime
On Sat, Mar 22, 2008 at 11:14:28PM -0300, =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves_ wrote: Which methods used to prevent OS detection and uptime (nmap) ? http://nmap.org/misc/defeat-nmap-osdetect.html#BSD I tried, but not work. The TCP Drop SYN+FIN sysctl might help. % sysctl -d net.inet.tcp.drop_synfin net.inet.tcp.drop_synfin: Drop TCP packets with SYN+FIN set Regards. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cx_lowest and CPU usage
Andriy Gapon wrote: on 20/02/2008 20:33 Andriy Gapon said the following: on 19/02/2008 23:42 Andriy Gapon said the following: The last result most probably means that RTC IRQ was not the interrupt to wake CPU from sleeping state. The first possibility that comes to mind is that on this particular hardware RTC interrupt (IRQ8) is not able to wake the system from C2 state. So it seems that this was true. Here's a shortcut to the relevant info: PIIX4E (FW82371EB) specification DEVACTB — DEVICE ACTIVITY B (FUNCTION 3) pci register description BRLD_EN_IRQ8, bit 5 $ pciconf -r pci0:0:7:3 0x58 03040c07 Attached is a patch that fixes the issue for me (without any side-effects) and should not cause any harm for others. I committed your patch. Thanks! Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cx_lowest and CPU usage
I'll handle this. Thanks!
On Feb 22, 2008, at 4:04 PM, Andriy Gapon wrote:
on 20/02/2008 20:33 Andriy Gapon said the following:
on 19/02/2008 23:42 Andriy Gapon said the following:
The last result most probably means that RTC IRQ was not the
interrupt
to wake CPU from sleeping state.
The first possibility that comes to mind is that on this particular
hardware RTC interrupt (IRQ8) is not able to wake the system from
C2 state.
So it seems that this was true.
Here's a shortcut to the relevant info:
PIIX4E (FW82371EB) specification
DEVACTB — DEVICE ACTIVITY B (FUNCTION 3) pci register description
BRLD_EN_IRQ8, bit 5
$ pciconf -r pci0:0:7:3 0x58
03040c07
Attached is a patch that fixes the issue for me (without any
side-effects) and should not cause any harm for others.
--
Andriy Gapon
--- acpi_cpu.c.orig 2008-02-21 21:08:16.0 +0200
+++ acpi_cpu.c 2008-02-21 21:13:54.0 +0200
@@ -113,6 +113,12 @@
#define PCI_REVISION_B_STEP 1
#define PCI_REVISION_4E 2
#define PCI_REVISION_4M 3
+#define PIIX4_DEVACTB_REG 0x58
+#define PIIX4_BRLD_EN_IRQ0 (10)
+#define PIIX4_BRLD_EN_IRQ (11)
+#define PIIX4_BRLD_EN_IRQ8 (15)
+#define PIIX4_STOP_BREAK_MASK (PIIX4_BRLD_EN_IRQ0 |
PIIX4_BRLD_EN_IRQ | PIIX4_BRLD_EN_IRQ8)
+#define PIIX4_PCNTRL_BST_EN(110)
/* Platform hardware resource information. */
static uint32_t cpu_smi_cmd; /* Value to write to SMI_CMD. */
@@ -1004,6 +1010,7 @@
acpi_cpu_quirks(void)
{
device_t acpi_dev;
+uint32_t val;
ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
@@ -1052,12 +1059,25 @@
* See erratum #18 (C3 Power State/BMIDE and Type-F DMA
* Livelock) from the January 2002 PIIX4 specification update.
* Applies to all PIIX4 models.
+*
+* Also, make sure that all interrupts cause a Stop Break
+* event to exit from C2 state.
*/
+ case PCI_REVISION_A_STEP:
+ case PCI_REVISION_B_STEP:
case PCI_REVISION_4E:
case PCI_REVISION_4M:
cpu_quirks |= CPU_QUIRK_NO_C3;
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
acpi_cpu: working around PIIX4 bug, disabling C3\n));
+
+ val = pci_read_config(acpi_dev, PIIX4_DEVACTB_REG, 4);
+ if ((val PIIX4_STOP_BREAK_MASK) != PIIX4_STOP_BREAK_MASK) {
+ ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+ PIIX4: enabling IRQs to generate Stop Break\n));
+ val |= PIIX4_STOP_BREAK_MASK;
+ pci_write_config(acpi_dev, PIIX4_DEVACTB_REG, val, 4);
+ }
break;
default:
break;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-
[EMAIL PROTECTED]
--
Rui Paulo
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
At Mon, 11 Jun 2007 13:12:04 -0700, Chuck Swiger wrote: If you ever use it, fdisk /dev/rdisk0 will show things differently. The first partition with id 0xEE will should start at LBA 40 and end at LBA 409640. OK: although that surprises me a bit, perhaps trying to get Windows XP (which may not understand the ~32 sector GPT header+table) means that claiming the first partition in the MBR starts at 40 works better...? Well, yes. I think it's like a safe keeping issue so that the user doesn't overwrite the GPT info. The first, small partition is almost certainly a boothfs boot partition, as described in the man page for Apple's version of fdisk: I don't think so. The boothfs partition doesn't seem to be used on Intel Macs no longer. The EFI boot loader that comes with Intel Macs can read HFS+ without any help (actually it's an EFI module), so bootufs/boothfs partitions are no longer required. It looks like you're right-- the OS-X formatting utilities still reserve space for the boot partition, but they just scribble enough to this space to indicate that the partition isn't actually bootable: # dd if=/dev/disk0s1 bs=512 count=409600 | hexdump -C Yes, this partition is just FAT32 without anything in it. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
At Mon, 11 Jun 2007 13:33:42 -0700 (PDT), Matthew Dillon wrote: : # gpt -r show /dev/rdisk0 :start size index contents :0 1 PMBR :1 1 Pri GPT header :2 32 Pri GPT table : 34 6 : 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B- : : 409640 159414704 2 GPT part - 48465300--11AA-AA11- : :... : Well, what's happening is that Boot Camp syncs the BIOS partition : table with the GPT table, so the first partition should start at 40, : just like the GPT. : : Why does it start at 40 ? Because you need room for the PMBR, the : Primary GPT header and the Primary GPT table. : :Agreed, you need about 32 sectors for the GPT header+table. It makes sense for them to point the first MBR slice at the first partition in the GPT, even though the standard says something else. It really sounds like they are making an accomodation for BIOS booting or older Windows booting... or *something* of that sort. The fact that the bootability bit is not set in the MBR (I'm not sure about that, is it set or not?)... that seems to imply a compatibility issue with other OS's like Windows in a multi-boot environment. They are just doing it all with a single slice instead of having two slices. I'll bet they found that the two-slice method doesn't work in some cases and the one-slice method does. The standard document doesn't allow either method but it does seem to be a bit less insistent on the starting sector for slice 1 then it does on there only being one slice in the MBR, period. I can also see some OS's / disk managers barfing on having two slices which overlap each other. So it really does make sense for them to point the MBR at sector 40. The more I think about it, the more sense it makes. And also, if they used two partitions that would mean you would only have one partition left for installing Windows. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
At Mon, 11 Jun 2007 12:41:18 -0700, Chuck Swiger wrote: Hi, all-- On Jun 10, 2007, at 3:13 PM, Rui Paulo wrote: :Media sector size is 512 :Warning: BIOS sector numbering starts with sector 1 :Information from DOS bootblock is: :The data for partition 1 is: :sysid 238 (0xee),(EFI GPT) :start 40, size 409600 (200 Meg), flag 0 :beg: cyl 0/ head 0/ sector 41; :end: cyl 406/ head 6/ sector 14 I think I have it mostly figured out, but the 'start 40' in your output can't be right. The intel documentation says that the starting LBA in a PMBR record must be set to 1 by definition (table 11-7 in the 1.10 documentation). I don't know why Apple does that. The offset of 40 sectors sounds like it is pointing to the first partition listed within the GPT? A typical Intel Mac system using GPT ought to look something like this: # fdisk /dev/rdisk0 Disk: /dev/rdisk0 geometry: 9964/255/63 [160086528 sectors] Signature: 0xAA55 Starting Ending #: id cyl hd sec - cyl hd sec [ start - size] 1: EE 1023 254 63 - 1023 254 63 [ 1 - 160086520] Unknown ID 2: 000 0 0 -0 0 0 [ 0 - 0] unused 3: 000 0 0 -0 0 0 [ 0 - 0] unused 4: 000 0 0 -0 0 0 [ 0 - 0] unused # gpt -r show /dev/rdisk0 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 6 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B- 409640 159414704 2 GPT part - 48465300--11AA-AA11- 159824344 262151 160086495 32 Sec GPT table 160086527 1 Sec GPT header Well, what's happening is that Boot Camp syncs the BIOS partition table with the GPT table, so the first partition should start at 40, just like the GPT. Why does it start at 40 ? Because you need room for the PMBR, the Primary GPT header and the Primary GPT table. Now, you don't seem to have used Boot Camp on your Mac, right? If you ever use it, fdisk /dev/rdisk0 will show things differently. The first partition with id 0xEE will should start at LBA 40 and end at LBA 409640. The first, small partition is almost certainly a boothfs boot partition, as described in the man page for Apple's version of fdisk: I don't think so. The boothfs partition doesn't seem to be used on Intel Macs no longer. The EFI boot loader that comes with Intel Macs can read HFS+ without any help (actually it's an EFI module), so bootufs/boothfs partitions are no longer required. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
At Sun, 10 Jun 2007 23:13:59 +0100, Rui Paulo wrote: At Sun, 10 Jun 2007 14:43:26 -0700 (PDT), Matthew Dillon wrote: :No. :The first partition is the EFI GPT (0xee): : :% fdisk -1 :*** Working on device /dev/ad0 *** :... :parameters to be used for BIOS calculations are: :cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) : :Media sector size is 512 :Warning: BIOS sector numbering starts with sector 1 :Information from DOS bootblock is: :The data for partition 1 is: :sysid 238 (0xee),(EFI GPT) :start 40, size 409600 (200 Meg), flag 0 :beg: cyl 0/ head 0/ sector 41; :end: cyl 406/ head 6/ sector 14 I think I have it mostly figured out, but the 'start 40' in your output can't be right. The intel documentation says that the starting LBA in a PMBR record must be set to 1 by definition (table 11-7 in the 1.10 documentation). I don't know why Apple does that. Actually, I think I do. See my other email. Regards. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
At Sun, 10 Jun 2007 11:08:47 -0700, Marcel Moolenaar wrote: On Jun 10, 2007, at 10:52 AM, Matthew Dillon wrote: :Technically speaking, the MBR can only have a single partition of :type 0xEE that covers the whole disk. This is to protect the GPT :from MBR-specific tools that do not know about the GPT. This is :not a bootable slice by definition. : :Practice is different. To support bootcamp on Intel-based Macs, :the MBR will have real partitions that mirror GPT partitions or :otherwise describe partitions outside the GPT controlled area. :These can be bootable partitions and the protective partition :(the one with type 0xEE) will not cover the whole disk anymore. : :The nasty part is keeping MBR and GPT partitions in sync, so it :may be better to have the MBR partition fall outside the GPT :controlled area. This can be done because the GPT header contains :the LBA of the first and last sectors on the disk that can be :assigned to a partition. You can free up space for MBR partitions :after the primary GPT table by adjusting the first LBA. In the :MBR partition you can put a GPT aware boot loader that uses the :GPT to find the real partitions... : :-- :Marcel Moolenaar In the bootcamp approach, is the GPT (0xEE) slice the first slice, and the bootcamp slice the second slice? I'm assuming it is. Do they mirror a GPT partition or do they use the uncontrolled area approach? I seem to recall that the 0xEE partition is not the first, but rather the second or third. It would make sense, because it has no function other than to have the disk appear used. Bootcamp uses the mirroring approach. No. The first partition is the EFI GPT (0xee): % fdisk -1 *** Working on device /dev/ad0 *** parameters extracted from in-core disklabel are: cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 238 (0xee),(EFI GPT) start 40, size 409600 (200 Meg), flag 0 beg: cyl 0/ head 0/ sector 41; end: cyl 406/ head 6/ sector 14 % gpt -r show ad0 gpt show: ad0: Suspicious MBR at sector 0 start size index contents 0 1 MBR 1 1 Pri GPT header 2 32 Pri GPT table 34 6 40 409600 1 GPT part - EFI System 409640 41943040 2 GPT part - Apple HFS 42352680 74857527 3 GPT part - FreeBSD UFS/UFS2 117210207 32 Sec GPT table 117210239 1 Sec GPT header -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
At Sun, 10 Jun 2007 14:43:26 -0700 (PDT), Matthew Dillon wrote: :No. :The first partition is the EFI GPT (0xee): : :% fdisk -1 :*** Working on device /dev/ad0 *** :... :parameters to be used for BIOS calculations are: :cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) : :Media sector size is 512 :Warning: BIOS sector numbering starts with sector 1 :Information from DOS bootblock is: :The data for partition 1 is: :sysid 238 (0xee),(EFI GPT) :start 40, size 409600 (200 Meg), flag 0 :beg: cyl 0/ head 0/ sector 41; :end: cyl 406/ head 6/ sector 14 I think I have it mostly figured out, but the 'start 40' in your output can't be right. The intel documentation says that the starting LBA in a PMBR record must be set to 1 by definition (table 11-7 in the 1.10 documentation). I don't know why Apple does that. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
On 2005.10.29 00:01:42 -0600, M. Warner Losh wrote: | In message: [EMAIL PROTECTED] | Rui Paulo [EMAIL PROTECTED] writes: | : On 2005.10.26 10:22:52 -0700, Bill Studenmund wrote: | : | On Mon, Oct 24, 2005 at 10:35:47PM +0200, Hans Petter Selasky wrote: | : | | : | Main features: | : | | : | - Implements FreeBSD's devfs on NetBSD. | : | | : | In the past, we (NetBSD folks) have talked about a devfs. One issue that | : | has come up (I'll be honest, I've raised it a lot) is a desire to retain | : | permission changes across boots, and to tie devices (when possible) to a | : | device-specific attribute rather than a probe order. | : | | : | Does FreeBSD's devfs support locators and persistent information? Are | : | there plans to support something like that, if not? | : | : I remember Linux's devfs having a configure file for that particular | : objective. The user would set the permission flags in (I can't recall | : if this is the real name) /etc/devfsd.conf and let devfsd do the job. | : | : You could also use another directory for permissions, like /dev-state, | : but personally, I don't like this method. | : | : http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html#persistence | | FreeBSD also has a file that can be used to control the permissions | and ownerships at runtime. The persistance can be there, but isn't | there by default like the old nodes in /dev. The other problem I see here is how devfs works in single user mode where devfsd is not started and no permissions are set. How does FreeBSD solve this problem? -- Rui Paulo pgpCCvNW3htMU.pgp Description: PGP signature
