Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
Hello, Marek. You wrote 3 октября 2012 г., 23:17:35: atrtc0: AT realtime clock port 0x70-0x71 on acpi0 MS still the same in my environment, running FreeBSD 9.1 under ESXi5.1 host MS Do you have any solution? In my case it was local patch for exotic embedded chipset... -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [SPAM]Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
W dniu 2012-10-04 20:51, Lev Serebryakov pisze: Hello, Marek. You wrote 3 октября 2012 г., 23:17:35: atrtc0: AT realtime clock port 0x70-0x71 on acpi0 MS still the same in my environment, running FreeBSD 9.1 under ESXi5.1 host MS Do you have any solution? In my case it was local patch for exotic embedded chipset... Can you send me the patch so I can have a look if I don't use the same chipset ? Regards, -- Marek Salwerowicz ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [SPAM]Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
On Thu, 2012-10-04 at 22:24 +0200, Marek Salwerowicz wrote: W dniu 2012-10-04 20:51, Lev Serebryakov pisze: Hello, Marek. You wrote 3 октября 2012 г., 23:17:35: atrtc0: AT realtime clock port 0x70-0x71 on acpi0 MS still the same in my environment, running FreeBSD 9.1 under ESXi5.1 host MS Do you have any solution? In my case it was local patch for exotic embedded chipset... Can you send me the patch so I can have a look if I don't use the same chipset ? Regards, It is the patch attached to this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=170705 The patch fixes a problem with old AMD Geode chipsets, but causes a hang at atrtc attach when run under virtualbox, and I haven't had time yet to install and learn to use vbox enough to debug it. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
W dniu 2012-09-19 22:22, Lev Serebryakov pisze: Hello, Freebsd-current. I've upgraded my FreeBSD-CURRENT Virtual machine, which I use to build router's NanoBSD image, to today's morning (MSK time, GMT+4) revision. Unfortunately, I cannot provide exact version, as sources are in this unbootable VM too :) Kernel is GENERIC. VBox configuration is rather stander: 2 CPUs, ICH9, 2GB of RAM. Host is Windows 7/64bit. Booting hangs after (new?) line: atrtc0: AT realtime clock port 0x70-0x71 on acpi0 Hi, still the same in my environment, running FreeBSD 9.1 under ESXi5.1 host Do you have any solution? Regards, -- Marek Salwerowicz ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
Hello, Freebsd-current. You wrote 20 сентября 2012 г., 0:22:00: LS I've upgraded my FreeBSD-CURRENT Virtual machine, which I use to LS build router's NanoBSD image, to today's morning (MSK time, GMT+4) LS revision. Unfortunately, I cannot provide exact version, as sources LS are in this unbootable VM too :) Revision is 240689 It looks like patch to RTC which is useful on Geode LX causes this hang. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
240689 is a doc commit. Which commit is it really? :) Adrian On 19 September 2012 13:37, Lev Serebryakov l...@freebsd.org wrote: Hello, Freebsd-current. You wrote 20 сентября 2012 г., 0:22:00: LS I've upgraded my FreeBSD-CURRENT Virtual machine, which I use to LS build router's NanoBSD image, to today's morning (MSK time, GMT+4) LS revision. Unfortunately, I cannot provide exact version, as sources LS are in this unbootable VM too :) Revision is 240689 It looks like patch to RTC which is useful on Geode LX causes this hang. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
Hello, Adrian. You wrote 20 сентября 2012 г., 0:41:20: It looks like patch to RTC which is useful on Geode LX causes this hang. AC 240689 is a doc commit. Which commit is it really? :) I'm testing theory (build kernel from fresh sources), that it is caused by local RTC patch, which helps Geode. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
On Thu, 2012-09-20 at 00:37 +0400, Lev Serebryakov wrote: Hello, Freebsd-current. You wrote 20 сентября 2012 г., 0:22:00: LS I've upgraded my FreeBSD-CURRENT Virtual machine, which I use to LS build router's NanoBSD image, to today's morning (MSK time, GMT+4) LS revision. Unfortunately, I cannot provide exact version, as sources LS are in this unbootable VM too :) Revision is 240689 It looks like patch to RTC which is useful on Geode LX causes this hang. Yes, exactly. I updated the PR to request that my patch not get committed because it locks up virtualbox. I hope to find time soon to learn enough about installing/configuring virtualbox to figure out what the problem is (offhand,I suspect it hangs in the loop that probes for the need to re-index, because vbox doesn't quite emulate the hardware behavior fully). -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
Ah, what's the patch? adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
Hello, Ian. You wrote 20 сентября 2012 г., 0:46:24: IL Yes, exactly. I updated the PR to request that my patch not get IL committed because it locks up virtualbox. I hope to find time soon to IL learn enough about installing/configuring virtualbox to figure out what IL the problem is (offhand,I suspect it hangs in the loop that probes for IL the need to re-index, because vbox doesn't quite emulate the hardware IL behavior fully). How could I help? Is it possible to debug kernel on such early stage? -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
On 19 September 2012 13:54, Lev Serebryakov l...@freebsd.org wrote: Hello, Ian. You wrote 20 сентября 2012 г., 0:46:24: IL Yes, exactly. I updated the PR to request that my patch not get IL committed because it locks up virtualbox. I hope to find time soon to IL learn enough about installing/configuring virtualbox to figure out what IL the problem is (offhand,I suspect it hangs in the loop that probes for IL the need to re-index, because vbox doesn't quite emulate the hardware IL behavior fully). How could I help? Is it possible to debug kernel on such early stage? Add something to atrtc_start() to only loop over that loop say, 64k times before dropping out; and print an error if it hits that condition. Also, what's that RTCSA_8192 bit do? adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
On Wed, 2012-09-19 at 14:00 -0700, Adrian Chadd wrote: On 19 September 2012 13:54, Lev Serebryakov l...@freebsd.org wrote: Hello, Ian. You wrote 20 сентября 2012 г., 0:46:24: IL Yes, exactly. I updated the PR to request that my patch not get IL committed because it locks up virtualbox. I hope to find time soon to IL learn enough about installing/configuring virtualbox to figure out what IL the problem is (offhand,I suspect it hangs in the loop that probes for IL the need to re-index, because vbox doesn't quite emulate the hardware IL behavior fully). How could I help? Is it possible to debug kernel on such early stage? Add something to atrtc_start() to only loop over that loop say, 64k times before dropping out; and print an error if it hits that condition. Also, what's that RTCSA_8192 bit do? That should set the interrupt rate really high, to minimize the time wasted waiting for the status bit to change in the register. Maybe that's the part that vbox isn't emulating well and so it never simulates an interrupt and leaves that loop. Or maybe because the loop is a tight busy-wait the emulator never gets control to simulate the occurance of the interrupt. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
On 19 September 2012 14:05, Ian Lepore free...@damnhippie.dyndns.org wrote: Add something to atrtc_start() to only loop over that loop say, 64k times before dropping out; and print an error if it hits that condition. Also, what's that RTCSA_8192 bit do? That should set the interrupt rate really high, to minimize the time wasted waiting for the status bit to change in the register. Maybe that's the part that vbox isn't emulating well and so it never simulates an interrupt and leaves that loop. Or maybe because the loop is a tight busy-wait the emulator never gets control to simulate the occurance of the interrupt. Right. Being totally clueless, is atrc_start() called just at probe/attach, or during normal operation? adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
On Wed, 2012-09-19 at 14:08 -0700, Adrian Chadd wrote: On 19 September 2012 14:05, Ian Lepore free...@damnhippie.dyndns.org wrote: Add something to atrtc_start() to only loop over that loop say, 64k times before dropping out; and print an error if it hits that condition. Also, what's that RTCSA_8192 bit do? That should set the interrupt rate really high, to minimize the time wasted waiting for the status bit to change in the register. Maybe that's the part that vbox isn't emulating well and so it never simulates an interrupt and leaves that loop. Or maybe because the loop is a tight busy-wait the emulator never gets control to simulate the occurance of the interrupt. Right. Being totally clueless, is atrc_start() called just at probe/attach, or during normal operation? It's called just once, from the attach() routine for the rtc device. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
On 19 September 2012 14:12, Ian Lepore free...@damnhippie.dyndns.org wrote: Right. Being totally clueless, is atrc_start() called just at probe/attach, or during normal operation? It's called just once, from the attach() routine for the rtc device. Right. Just have it loop over say 100 times, with a 10us sleep between each. Shouldn't that be enough? Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
On Wed, 2012-09-19 at 14:30 -0700, Adrian Chadd wrote: On 19 September 2012 14:12, Ian Lepore free...@damnhippie.dyndns.org wrote: Right. Being totally clueless, is atrc_start() called just at probe/attach, or during normal operation? It's called just once, from the attach() routine for the rtc device. Right. Just have it loop over say 100 times, with a 10us sleep between each. Shouldn't that be enough? If by sleep you mean any form of pausing or sleeping that waits for a given amount of time... remember when this code is running we're still in the process of trying to figure out which clocks can be used for such purposes. That leaves DELAY(), which does pretty much the equivelent of what the loop in question is doing. Hmmm, but DELAY() does have the advantage of busy-looping for a known amount of time, making it easier to constrain the time spent in the loop regardless of the speed of the cpu. I'll have to look into how DELAY() is implemented for x86 and see if it's usable in this context. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
On Wed, Sep 19, 2012 at 1:46 PM, Ian Lepore free...@damnhippie.dyndns.org wrote: ... Yes, exactly. I updated the PR to request that my patch not get committed because it locks up virtualbox. I hope to find time soon to learn enough about installing/configuring virtualbox to figure out what the problem is (offhand,I suspect it hangs in the loop that probes for the need to re-index, because vbox doesn't quite emulate the hardware behavior fully). Why not just detect VBox and disable that functionality? VMware at least has a sane way of determining whether or not you're running it based on the SMBios ident.. Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
On 19 September 2012 14:57, Garrett Cooper yaneg...@gmail.com wrote: On Wed, Sep 19, 2012 at 1:46 PM, Ian Lepore free...@damnhippie.dyndns.org wrote: ... Yes, exactly. I updated the PR to request that my patch not get committed because it locks up virtualbox. I hope to find time soon to learn enough about installing/configuring virtualbox to figure out what the problem is (offhand,I suspect it hangs in the loop that probes for the need to re-index, because vbox doesn't quite emulate the hardware behavior fully). Why not just detect VBox and disable that functionality? VMware at least has a sane way of determining whether or not you're running it based on the SMBios ident.. Sure, but that doens't answer the underlying reason(s) of why is it failing?. :-) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
On Wed, 2012-09-19 at 15:10 -0700, Adrian Chadd wrote: On 19 September 2012 14:57, Garrett Cooper yaneg...@gmail.com wrote: On Wed, Sep 19, 2012 at 1:46 PM, Ian Lepore free...@damnhippie.dyndns.org wrote: ... Yes, exactly. I updated the PR to request that my patch not get committed because it locks up virtualbox. I hope to find time soon to learn enough about installing/configuring virtualbox to figure out what the problem is (offhand,I suspect it hangs in the loop that probes for the need to re-index, because vbox doesn't quite emulate the hardware behavior fully). Why not just detect VBox and disable that functionality? VMware at least has a sane way of determining whether or not you're running it based on the SMBios ident.. Sure, but that doens't answer the underlying reason(s) of why is it failing?. :-) Yeah, I'd much rather understand a problem than tap dance around it, at least for starters. Figuring out what's really going on may lead to a discovery that it would fail in other circumstances as well, or it may lead to a bugfix in vbox if that's where the problem lies. I'm just a bit too busy with $work right now to dig into it. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
On Wed, 19 Sep 2012 14:57:30 -0700, Garrett Cooper wrote: On Wed, Sep 19, 2012 at 1:46 PM, Ian Lepore free...@damnhippie.dyndns.org wrote: ... Yes, exactly. I updated the PR to request that my patch not get committed because it locks up virtualbox. I hope to find time soon to learn enough about installing/configuring virtualbox to figure out what the problem is (offhand,I suspect it hangs in the loop that probes for the need to re-index, because vbox doesn't quite emulate the hardware behavior fully). Why not just detect VBox and disable that functionality? VMware at least has a sane way of determining whether or not you're running it based on the SMBios ident.. VMware (as well as KVM and Xen) provides reliable way to detect its presence by checking hypervisor present CPUID's bit or accessing its I/O port, while VirtualBox doesn't do that, and matching SMBios ident doesn't seem to be really useful. Are there better and reliable ways of detecting VirtualBox? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org