Re: BTX loader hangs after version info
John Baldwin wrote: Try this patch. I'm not 100% certain this will fix it as I can't reproduce the issue, but I think it might help. Specifically, when the boot code makes a v86 call, the loader/boot2/whatever swaps in/out a new set of registers via the v86 structure including the eflags register. However, none of the boot programs actually initialized the v86 structure. Thus, the BIOS routines would start off running with whatever garbage was in v86.efl when each boot program started. This meant that we could end up invoking BIOS routines with interrupts disabled, and I think this might explain a hard hang (if a BIOS routine was waiting for an interrupt the interrupt would never fire). The patch fixes all the boot programs to initialize v86 to a better known state. At the least it sets v86.efl to a sane value (0x202) rather than random. (The random might have always been 0x0 BTW, not sure on that one.) Thanks John, Unfortunately this patch does *not* cure the issue for my old Supermicro P3TDDE, it still hangs just before presenting the menu. I had to boot off the livefs and copy /boot/loader.old -> /boot/loader to get back to being bootable again - but at least the old fella is on a more up-to-date 7-STABLE now :-) Cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BTX loader hangs after version info
I wrote: John Baldwin wrote: Try this patch. I'm not 100% certain this will fix it as I can't reproduce the issue, but I think it might help. Specifically, when the boot code makes a v86 call, the loader/boot2/whatever swaps in/out a new set of registers via the v86 structure including the eflags register. However, none of the boot programs actually initialized the v86 structure. Thus, the BIOS routines would start off running with whatever garbage was in v86.efl when each boot program started. This meant that we could end up invoking BIOS routines with interrupts disabled, and I think this might explain a hard hang (if a BIOS routine was waiting for an interrupt the interrupt would never fire). The patch fixes all the boot programs to initialize v86 to a better known state. At the least it sets v86.efl to a sane value (0x202) rather than random. (The random might have always been 0x0 BTW, not sure on that one.) Thanks John, Unfortunately this patch does *not* cure the issue for my old Supermicro P3TDDE, it still hangs just before presenting the menu. I had to boot off the livefs and copy /boot/loader.old -> /boot/loader to get back to being bootable again - but at least the old fella is on a more up-to-date 7-STABLE now :-) Given that the patch *did* cure Peters Tyan S2720, I'll double check I didn't fat finger applying the patch (mind you the Tyan has AMI BOIS - same as my Supermicro P3TDERs that *do* work ok with current 7-STABLE, whereas the P3TDDE has Award BIOS). Anyway, I'll double check and report back... Cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is it possible to create a directory under /dev?
On Fri, 23 May 2008 09:37:01 +0300
Andriy Gapon <[EMAIL PROTECTED]> wrote:
> >> But, by the way, there is a (slightly) more valid reason to want to
> >> create a directory under /dev, I recently had it. For one non-standard
> >> third-party application I needed to create a link to existing device in
> >> a certain subdirectory. I.e.:
> >> /dev/subdirX/device -> /dev/deviceX
> >> And I couldn't do that.
> >> Or maybe link operation for devfs just needs to be taught about creating
> >> subdirectories on demand. I don't know.
> >
> > you can create links with devfs - man devfs.conf
> > [...]
> > linkThis action creates a symbolic link named arg that points to
> > devname, the name of the device created by devfs(5).
> > [..]
>
> I do know that.
> Maybe I wasn't clear enough: "/dev/deviceX" was existing device node and
> I needed to create "/dev/subdirX/device" link, where directory
> "/dev/subdirX" didn't exist.
> Any help on this?
Not sure, but like someone mentioned parts of the system create this (geom?) .
you can check its code to see how its done.
good luck,
B
_
{Beto|Norberto|Numard} Meijome
Commitment is active, not passive. Commitment is doing whatever you can to
bring about the desired result. Anything less is half-hearted.
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is it possible to create a directory under /dev?
Please note that unionfs still has a few bugs! You will need at least patchset p19 for mounting devfs below/above unionfs mounts. There is also a patchset p20, still experimental, you might want to try it. -- Jille Oliver Fromme schreef: Andriy Gapon wrote: > But, by the way, there is a (slightly) more valid reason to want to > create a directory under /dev, I recently had it. For one non-standard > third-party application I needed to create a link to existing device in > a certain subdirectory. I.e.: > /dev/subdirX/device -> /dev/deviceX > And I couldn't do that. You could create a directory elsewhere and use UNIONFS to merge it with your existing /dev. I haven't tried this, but I think it should work. # mkdir /mydev # mount -t unionfs -o below /mydev /dev # cd /mydev # mkdir subdirX # ln -s /dev/deviceX subdirX/device The "-o below" option is used so that any modifications on /dev -- such as creating symlinks -- still happen on the real /dev, not on /mydev. Best regards Oliver ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_ule performance on single CPU
--- Chuck Swiger <[EMAIL PROTECTED]> wrote: > On May 23, 2008, at 6:37 PM, Unga wrote: > > When open an pdf has two types of scenarios in > FreeBSD: > > 1. When X run as a realtime-prio process, X go mad > and swallow up > > almost all of CPU cycles, making audio hiccups. > > > > 2. When X run as a normal-prio process, X behaves > well and rarely > > gets an audible hiccup. > > > > Why X behave different under different priority > categories? Isn't > > this scheduler related? > > Sure. To generalize, the traditional scheduler goal > for Unix has been > to maximize overall throughput and avoid starvation > of even low- > priority tasks, at the expense of higher and > unpredictable latency. > Using realtime priority means that the kernel is > told to minimize > latency for that process even if it means starving > other processes of > CPU time. > > That is well suited for things like CD/DVD burning > or audio/visual > capture, but as you've experienced yourself, it does > poorly for > heavily client-server oriented stuff like X11's > architecture. > > > I wonder the issue I mentioned, open a pdf while > playback audio, is > > it a issue on Apple Mac OSX? > > Nope. :-) > > > Could somebody give some light here who uses an > Apple Mac OSX on > > this list? > > > > If it is not an issue in Mac OSX, how they have > overcome it then? > > > While both FreeBSD and MacOS X are general-purpose > operating systems, > doing multimedia creation and playback is among the > primary > functionality goals for MacOS X, in much the same > way that FreeBSD > regards providing "robust network services" like > Apache, DNS, email, > databases and so forth. > > Core Audio is probably the biggest user of realtime > thread scheduling > under MacOS X, followed by QuickTime or DVD playback > over Core Video. > These frameworks were designed to handle multimedia > without skipping > by preallocating sensible amounts of buffer space, > and they take > advantage of the Mach kernel and IOKit drivers which > are intended to > support realtime needs. Unlike the traditional BSD > kernels, the Mach > kernel was originally designed with SMP, soft & hard > realtime > scheduling in the kernel. The original userland > threads library which > came with Mach, called CThreads, was largely > responsible for the > design that was abstracted into the portable POSIX > threads model > widely used today. > > After FreeBSD 4, there has been a tremendous amount > of work in the > kernel on fine-grained locking and moving device > drivers from running > in the non-preemptable interrupt context to having > device kernel > threads which can be preempted, and there has also > been a lot of work > on the userland side to improve the C threading > libraries and to > improve multithreaded malloc() performance via > jemalloc, but this is > still ongoing and higher level applications like X11 > programs haven't > had years to adapt and take advantage of these > changes. > > Simple things like auto-tuning the size of the audio > buffers to avoid > or minimize skipping or dropouts isn't really in > place yet with > FreeBSD. Realtime video on FreeBSD is dependent > upon X11, which was > originally designed by a bunch of guys at MIT to be > able to display > lots of xterms or other things involving simple > blits of bits, > possibly over the network, in order to replace the > Andrew window > manager system used by CMU, MIT, IBM, and a few > others. X11 wasn't > designed to do alpha channel (aka transparency), > much less stream a > couple of hundred MB per second of data for realtime > OpenGL texturing > or video. (Although, Composite and GLX have since > been added to X11, > they are extensions rather than core functionality, > and hardware > driver support for GLX is less than perfectly > available, especially > once you start looking at the AMD64/EM64T platform, > rather than 32-bit > x86) > > There's a 2002 BSDcon paper here, written around the > time of FreeBSD > 5.x's release, which has more details: > > http://www.usenix.org/events/bsdcon02/full_papers/gerbarg/gerbarg_html/ > Thank you very much for the detailed info. It seems FreeBSD may need two schedulers, one for desktop and one for server, among other things. Kind regards Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BTX loader hangs after version info
On Sun, May 25, 2008 at 08:33:01PM +1200, Mark Kirkwood wrote: > I wrote: > >John Baldwin wrote: > >> > >>Try this patch. I'm not 100% certain this will fix it as I can't > >>reproduce > >>the issue, but I think it might help. Specifically, when the boot > >>code makes > >>a v86 call, the loader/boot2/whatever swaps in/out a new set of > >>registers via > >>the v86 structure including the eflags register. However, none of > >>the boot > >>programs actually initialized the v86 structure. Thus, the BIOS > >>routines > >>would start off running with whatever garbage was in v86.efl when > >>each boot > >>program started. This meant that we could end up invoking BIOS > >>routines with > >>interrupts disabled, and I think this might explain a hard hang (if a > >>BIOS > >>routine was waiting for an interrupt the interrupt would never > >>fire). The > >>patch fixes all the boot programs to initialize v86 to a better known > >>state. At the least it sets v86.efl to a sane value (0x202) rather > >>than random. (The > >>random might have always been 0x0 BTW, not sure on that one.) > >> > >> > >Thanks John, > > > >Unfortunately this patch does *not* cure the issue for my old > >Supermicro P3TDDE, it still hangs just before presenting the menu. I > >had to boot off the livefs and copy /boot/loader.old -> /boot/loader > >to get back to being bootable again - but at least the old fella is on > >a more up-to-date 7-STABLE now :-) > > Given that the patch *did* cure Peters Tyan S2720, I'll double check I > didn't fat finger applying the patch (mind you the Tyan has AMI BOIS - > same as my Supermicro P3TDERs that *do* work ok with current 7-STABLE, > whereas the P3TDDE has Award BIOS). > > Anyway, I'll double check and report back... > > Cheers > > Mark I now have booted some more with this patch and it would seem that the problem is still there, from time to time! Most of the time I now boot without any problems but once in a while the loader still hangs. I'll try to gather some statistics... -- Peter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What does system do after "Uptime: "?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gavin Atkinson wrote: | On Thu, 2008-05-01 at 09:58 -0700, Xin LI wrote: |> -BEGIN PGP SIGNED MESSAGE- |> Hash: SHA1 |> |> Gavin Atkinson wrote: |> | FWIW, there have been probably around 10 PRs in in the last few months |> | about this behaviour. I'd vote for it as an errata candidate. |> |> FWIW I have written to re@ indicating some changes I wanted for |> RELENG_7_0 as candidates. Could you please let me know if I have missed |> something important? |> |> http://www.delphij.net/errata-20080430.xml | | Did you get anywhere with this request? PRs are still coming in about | the "hang after Uptime:" issue. | | If the errata candidates were turned down, I think we need to have an | entry in the release notes errata... The latest list is: http://www.delphij.net/errata-20080511.xml And what would be finally made into errata is still under discussion. Cheers, - -- ** Help China's quake relief at http://www.redcross.org.cn/ |>> Xin LI <[EMAIL PROTECTED]>http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkg5jjEACgkQi+vbBBjt66BmUACfUWWd1M3Ribis+YvvhEb78mlS 5LsAoLhcGhxBbpHBzUjVVVgB+M3IAnmM =aI4C -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BTX loader hangs after version info
On Sun, May 25, 2008 at 08:33:01PM +1200, Mark Kirkwood wrote: > I wrote: > >John Baldwin wrote: > >> > >>Try this patch. I'm not 100% certain this will fix it as I can't > >>reproduce > >>the issue, but I think it might help. Specifically, when the boot > >>code makes > >>a v86 call, the loader/boot2/whatever swaps in/out a new set of > >>registers via > >>the v86 structure including the eflags register. However, none of > >>the boot > >>programs actually initialized the v86 structure. Thus, the BIOS > >>routines > >>would start off running with whatever garbage was in v86.efl when > >>each boot > >>program started. This meant that we could end up invoking BIOS > >>routines with > >>interrupts disabled, and I think this might explain a hard hang (if a > >>BIOS > >>routine was waiting for an interrupt the interrupt would never > >>fire). The > >>patch fixes all the boot programs to initialize v86 to a better known > >>state. At the least it sets v86.efl to a sane value (0x202) rather > >>than random. (The > >>random might have always been 0x0 BTW, not sure on that one.) > >> > >> > >Thanks John, > > > >Unfortunately this patch does *not* cure the issue for my old > >Supermicro P3TDDE, it still hangs just before presenting the menu. I > >had to boot off the livefs and copy /boot/loader.old -> /boot/loader > >to get back to being bootable again - but at least the old fella is on > >a more up-to-date 7-STABLE now :-) > > Given that the patch *did* cure Peters Tyan S2720, I'll double check I > didn't fat finger applying the patch (mind you the Tyan has AMI BOIS - > same as my Supermicro P3TDERs that *do* work ok with current 7-STABLE, > whereas the P3TDDE has Award BIOS). > > Anyway, I'll double check and report back... > > Cheers > > Mark I did 18 boots with and with out John's patch. With the patch I got 6 actual boots and 12 hangs in the loaders progress bar. Without the patch I got 10 boots and 8 hangs. But, my Tyan M/B is old and with known ACPI issues so I'm not sure if this is of much value. Mark, it would be nice if you also observe if a sequence of reboots eventually boots your system. My longest bad streek was 8 reboots. - Peter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BTX loader hangs after version info
Peter Holm wrote: On Sun, May 25, 2008 at 08:33:01PM +1200, Mark Kirkwood wrote: I wrote: John Baldwin wrote: Try this patch. I'm not 100% certain this will fix it as I can't reproduce the issue, but I think it might help. Specifically, when the boot code makes a v86 call, the loader/boot2/whatever swaps in/out a new set of registers via the v86 structure including the eflags register. However, none of the boot programs actually initialized the v86 structure. Thus, the BIOS routines would start off running with whatever garbage was in v86.efl when each boot program started. This meant that we could end up invoking BIOS routines with interrupts disabled, and I think this might explain a hard hang (if a BIOS routine was waiting for an interrupt the interrupt would never fire). The patch fixes all the boot programs to initialize v86 to a better known state. At the least it sets v86.efl to a sane value (0x202) rather than random. (The random might have always been 0x0 BTW, not sure on that one.) Thanks John, Unfortunately this patch does *not* cure the issue for my old Supermicro P3TDDE, it still hangs just before presenting the menu. I had to boot off the livefs and copy /boot/loader.old -> /boot/loader to get back to being bootable again - but at least the old fella is on a more up-to-date 7-STABLE now :-) Given that the patch *did* cure Peters Tyan S2720, I'll double check I didn't fat finger applying the patch (mind you the Tyan has AMI BOIS - same as my Supermicro P3TDERs that *do* work ok with current 7-STABLE, whereas the P3TDDE has Award BIOS). Anyway, I'll double check and report back... Cheers Mark I did 18 boots with and with out John's patch. With the patch I got 6 actual boots and 12 hangs in the loaders progress bar. Without the patch I got 10 boots and 8 hangs. But, my Tyan M/B is old and with known ACPI issues so I'm not sure if this is of much value. Mark, it would be nice if you also observe if a sequence of reboots eventually boots your system. My longest bad streek was 8 reboots. Ok, will do. Incidentally, checking showed that the patch *was* correctly applied. I'll report back in several reboots :-) Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BTX loader hangs after version info
Peter Holm wrote: On Sun, May 25, 2008 at 08:33:01PM +1200, Mark Kirkwood wrote: I wrote: John Baldwin wrote: Try this patch. I'm not 100% certain this will fix it as I can't reproduce the issue, but I think it might help. Specifically, when the boot code makes a v86 call, the loader/boot2/whatever swaps in/out a new set of registers via the v86 structure including the eflags register. However, none of the boot programs actually initialized the v86 structure. Thus, the BIOS routines would start off running with whatever garbage was in v86.efl when each boot program started. This meant that we could end up invoking BIOS routines with interrupts disabled, and I think this might explain a hard hang (if a BIOS routine was waiting for an interrupt the interrupt would never fire). The patch fixes all the boot programs to initialize v86 to a better known state. At the least it sets v86.efl to a sane value (0x202) rather than random. (The random might have always been 0x0 BTW, not sure on that one.) Thanks John, Unfortunately this patch does *not* cure the issue for my old Supermicro P3TDDE, it still hangs just before presenting the menu. I had to boot off the livefs and copy /boot/loader.old -> /boot/loader to get back to being bootable again - but at least the old fella is on a more up-to-date 7-STABLE now :-) Given that the patch *did* cure Peters Tyan S2720, I'll double check I didn't fat finger applying the patch (mind you the Tyan has AMI BOIS - same as my Supermicro P3TDERs that *do* work ok with current 7-STABLE, whereas the P3TDDE has Award BIOS). Anyway, I'll double check and report back... Cheers Mark I did 18 boots with and with out John's patch. With the patch I got 6 actual boots and 12 hangs in the loaders progress bar. Without the patch I got 10 boots and 8 hangs. But, my Tyan M/B is old and with known ACPI issues so I'm not sure if this is of much value. Mark, it would be nice if you also observe if a sequence of reboots eventually boots your system. My longest bad streek was 8 reboots. Yeah, I see the same thing - with John's patch applied, out of 9 reboots I got 7 hangs and 2 actual boots. (didn't try without the patch). Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Why does sysinstall still limits cylinders to 65535?
Hello, I have been struglling with sysinstall, attempting to make it handle the geometry of some large SATA drives. After a lot of effort I decided to stop suffering and modified the program in order to circumvent the outdated limit of 65535 cylinders (see attached patch). I'm thinking about submitting a PR with a change request but I'd like to get some additional opinions first. I did not test it in "batch" mode, so it would be great if any kind soul did this. Thanks in advance for your comments and/or suggestions. -- Carlos A. M. dos Santos sysinstall-64kcyl.diff Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BTX loader hangs after version info
On Mon, May 26, 2008 at 02:23:11PM +1200, Mark Kirkwood wrote: > Peter Holm wrote: > >On Sun, May 25, 2008 at 08:33:01PM +1200, Mark Kirkwood wrote: > > > >>I wrote: > >> > >>>John Baldwin wrote: > >>> > Try this patch. I'm not 100% certain this will fix it as I can't > reproduce > the issue, but I think it might help. Specifically, when the boot > code makes > a v86 call, the loader/boot2/whatever swaps in/out a new set of > registers via > the v86 structure including the eflags register. However, none of > the boot > programs actually initialized the v86 structure. Thus, the BIOS > routines > would start off running with whatever garbage was in v86.efl when > each boot > program started. This meant that we could end up invoking BIOS > routines with > interrupts disabled, and I think this might explain a hard hang (if a > BIOS > routine was waiting for an interrupt the interrupt would never > fire). The > patch fixes all the boot programs to initialize v86 to a better known > state. At the least it sets v86.efl to a sane value (0x202) rather > than random. (The > random might have always been 0x0 BTW, not sure on that one.) > > > > >>>Thanks John, > >>> > >>>Unfortunately this patch does *not* cure the issue for my old > >>>Supermicro P3TDDE, it still hangs just before presenting the menu. I > >>>had to boot off the livefs and copy /boot/loader.old -> /boot/loader > >>>to get back to being bootable again - but at least the old fella is on > >>>a more up-to-date 7-STABLE now :-) > >>> > >>Given that the patch *did* cure Peters Tyan S2720, I'll double check I > >>didn't fat finger applying the patch (mind you the Tyan has AMI BOIS - > >>same as my Supermicro P3TDERs that *do* work ok with current 7-STABLE, > >>whereas the P3TDDE has Award BIOS). > >> > >>Anyway, I'll double check and report back... > >> > >>Cheers > >> > >>Mark > >> > > > >I did 18 boots with and with out John's patch. With the patch I got 6 > >actual boots and 12 hangs in the loaders progress bar. > > > >Without the patch I got 10 boots and 8 hangs. > > > >But, my Tyan M/B is old and with known ACPI issues so I'm not sure if > >this is of much value. > > > >Mark, it would be nice if you also observe if a sequence of reboots > >eventually boots your system. My longest bad streek was 8 reboots. > > > > > > Yeah, I see the same thing - with John's patch applied, out of 9 reboots > I got 7 hangs and 2 actual boots. (didn't try without the patch). > > Mark OK, that is at least nice with consistency across different HW. -- Peter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Why does sysinstall still limits cylinders to 65535?
On Sun, May 25, 2008 at 11:52:06PM -0300, Carlos A. M. dos Santos wrote: > I have been struglling with sysinstall, attempting to make it handle > the geometry of some large SATA drives. After a lot of effort I > decided to stop suffering and modified the program in order to > circumvent the outdated limit of 65535 cylinders (see attached patch). > I'm thinking about submitting a PR with a change request but I'd like > to get some additional opinions first. I did not test it in "batch" > mode, so it would be great if any kind soul did this. Carlos, bottom line is to simply ignore the geometry warning you see. For others... This is just added evidence that the humongous warning spit out during sysinstall's fdisk is confusing users (many taking it very seriously when there's really no problem at all). I think this is the third time someone's brought this up in the past couple months... -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
