Re: DPMS broken on ThinkPad T43 since update for amd64 support
On Mar 18, 2010, at 20:42, Ian Smith wrote: On Thu, 18 Mar 2010, Kevin Oberman wrote: Since the update of DPMS to support amd64 on March 2, it has broken rather badly on my ThinkPad T43 laptop. The problem showed up on 8-stable built on March 3 and is still present after an update to stable of March 17. When in vty text mode, after the idle normal delay, the display blanks, but the backlight remains on, so the P in DPMS seems to be less than effective. At that point, the non-graphics display is dead. It never comes back when characters are entered. I can't get the display to come back without a reboot. I can, however, start X (and Gnome) and everything is fine. But switching back to any vty results in a blank screen. Any idea what happened and if there is a fix or workaround? Any data I can collect? Have you tried kldloading vesa? Might be a workaround until you find a proper fix? Had a similar issue with my T23 at one stage on 7.0, after a suspend/resume cycle, which hw.syscons.sc_no_suspend_vtswitch=1 also helped .. no idea how the T43 might respond to the latter. Thanks, Ian, but it didn't help. The hw.syscons.sc_no_suspend_vtswitch sysctl is only relevant to resuming from suspend and I think I was the one who suggested it to you. I used to have T23 & used it on that systeem. Thanks for the suggestions, though. Sent from my iPod ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: DPMS broken on ThinkPad T43 since update for amd64 support
On Thu, 18 Mar 2010, Kevin Oberman wrote: > Since the update of DPMS to support amd64 on March 2, it has broken > rather badly on my ThinkPad T43 laptop. The problem showed up on > 8-stable built on March 3 and is still present after an update to stable > of March 17. > > When in vty text mode, after the idle normal delay, the display blanks, > but the backlight remains on, so the P in DPMS seems to be less than > effective. At that point, the non-graphics display is dead. It never > comes back when characters are entered. I can't get the display to come > back without a reboot. > > I can, however, start X (and Gnome) and everything is fine. But > switching back to any vty results in a blank screen. > > Any idea what happened and if there is a fix or workaround? Any data I > can collect? Have you tried kldloading vesa? Might be a workaround until you find a proper fix? Had a similar issue with my T23 at one stage on 7.0, after a suspend/resume cycle, which hw.syscons.sc_no_suspend_vtswitch=1 also helped .. no idea how the T43 might respond to the latter. FWIW, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.2-p7 -> 8-STABLE mergemaster core dump
Hello Toma, Adam, Jeremy and all. Thanks a lot for the comments. Very very helpful. I haven't tried the KVM over IP but willl look at it. In my case one the servers is on a remote site , in other country and for the prices when they have to "put hands in you server" for sure will be cheaper to buy the kvm and sent it to them. They charge for event and besides for time. With FreeBsd 4.3 never had a problem doing things that way but now is something very important to consider. Thanks a lot. JB At 11:55 a.m. 18/03/2010, Tom Evans wrote: On Thu, Mar 18, 2010 at 5:27 PM, Jorge Biquez wrote: > Hello all. > With all respect Doug, users that have remote machines and do not have > access to it to boot single user like the manual says.. what can we do? I > understand that step is to be sure that no user will modify something while > we are doing those process. In my case I do that step after midnight when > our users are not in the server. > > Can others with remote systems comment about what they do in this step? > > Thanks in advance > > Jorge Biquez > > Hi Jorge As I mentioned in my email, the critical thing is that you must be running your new kernel before installing your new world. The single-user phase is simply to ensure that nothing is running that would interfere with the installworld/mergemaster steps. Therefore, an appropriate workaround if you cannot go to single user mode remotely would be to install the kernel, reboot into the new kernel, install world, reboot into the new world. However, if you have no remote access at all (remote power would be better than nothing!) this would be quite risky. Judicious use of nextboot, and having someone on standby who can find the power button is recommended. Cheers Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Fatal trap 12: page fault while in kernel mode/current process: 12 (swi2: cambio)
On 03/16/10 00:04, O. Hartmann wrote: On 03/15/10 18:30, Matthew Fleming wrote: Since the last update and make world on Friday, 12th March I get a crash on one of my FreeBSD SMP boxes (it is always the same core message), saying something about Fatal trap 12: page fault while in kernel mode [...] current process: 12 (swi2: cambio) Can you show the stack traceback from the kernel core? We had a problem a while ago at Isilon that I can't tell if it's related. In our case, the camisr() routine was called after panic(9) started and before the halt of other processors. This did Bad Things(TM) since the mtx_lock is a no-op after panicstr is set. We solved it locally by wrapping camisr() in a local cambio_swi() routine that only called camisr(NULL) when panicstr == NULL. Thanks, matthew Hello. I will do as soon as possible. The box is in production at the moment and I've less time to put everything into debugging to provide more details. Just in case: does the kernel automatically save the screen with the dump information? If not, I have no other terminal facility to get a dump via the classical way. Regards, Oliver Since yesterday, this problem went away! This is mystical. After deactivating radeon.ko and the virtual box stuff I tried again with a new build of world and - voila! - everything worked again. This is strange ... Oliver ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Strange problem: if_xe only works in GENERIC kernel
Lowell Gilbert wrote: > Try "device cbb". Also make sure you have pccard. I don't think > you'll need cardbus with that setup, but I'm not certain. cbb, pccard, and also cardbus are part of the kernel config. I originally left out xe on purpose (so I could e.g. recompile it while the machine is running), but even when I include it, the problem remains. It's something else, but I've got no idea what. The really bad thing is that it completely halts the machine until pulling the card. I've been using that very same card in that TP 600E regularly years before, with older FreeBSD versions, without much problems. (There's a generic problem on the TP600 where you have to provide an explicit memory start address beyond regular RAM in loader.conf, e.g. hw.cbb.start_memory=0x2000.) -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Strange problem: if_xe only works in GENERIC kernel
Joerg Wunsch writes: > I'm running into a strange problem with 8-current (or 8.0-RELEASE) on > an elderly Thinkpad 600E. > > As long as I'm using the GENERIC kernel, an Intel Etherexpress PC card > works as expected: > > interrupt storm detected on "irq11:"; throttling interrupt source > xe0: at port > 0x100-0x10f iomem 0x2000-0x2fff irq 11 function 0 config 1 on pccard1 > xe0: version 0x45/0x04, 100Mbps capable > xe0: Ethernet address: 00:a0:c9:bc:b5:ef > xe0: [ITHREAD] > > However, as soon as I start removing unneeded stuff from the kernel > config file, the driver completely jams. It just sits there, the > machine blocks, until I eventually pop out the card, when I get the > following messages: > > cbb1: ready never happened, status = 00 > xe0: at port > 0x100-0x10f iomem 0x2000-0x2fff irq 11 function 0 config 1 on pccard1 > xe0: version 0xff/0x07, 100Mbps capable > xe0: Ethernet address: 00:a0:c9:bc:b5:ef > xe0: [ITHREAD] > xe0: detached > cbb1: Bad Vcc requested > As the CPU is a little slow, recompiling kernels takes an eternity on > it (even with NO_KERNELCLEAN), so I could not isolate it to a single > line in the config file so far. Try "device cbb". Also make sure you have pccard. I don't think you'll need cardbus with that setup, but I'm not certain. I'm not sure about this, because I wouldn't really expect the xe driver to attach at all without pccard working, but you definitely need those in your case. Or maybe I'm way off base, since the comments in the GENERIC file would probably warn you not to delete those. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Strange problem: if_xe only works in GENERIC kernel
I'm running into a strange problem with 8-current (or 8.0-RELEASE) on an elderly Thinkpad 600E. As long as I'm using the GENERIC kernel, an Intel Etherexpress PC card works as expected: interrupt storm detected on "irq11:"; throttling interrupt source xe0: at port 0x100-0x10f iomem 0x2000-0x2fff irq 11 function 0 config 1 on pccard1 xe0: version 0x45/0x04, 100Mbps capable xe0: Ethernet address: 00:a0:c9:bc:b5:ef xe0: [ITHREAD] However, as soon as I start removing unneeded stuff from the kernel config file, the driver completely jams. It just sits there, the machine blocks, until I eventually pop out the card, when I get the following messages: cbb1: ready never happened, status = 00 xe0: at port 0x100-0x10f iomem 0x2000-0x2fff irq 11 function 0 config 1 on pccard1 xe0: version 0xff/0x07, 100Mbps capable xe0: Ethernet address: 00:a0:c9:bc:b5:ef xe0: [ITHREAD] xe0: detached cbb1: Bad Vcc requested As the CPU is a little slow, recompiling kernels takes an eternity on it (even with NO_KERNELCLEAN), so I could not isolate it to a single line in the config file so far. Upgrading from 8.0-RELEASE to 8-stable does not change that behaviour. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: DPMS broken on ThinkPad T43 since update for amd64 support
> Date: Thu, 18 Mar 2010 10:01:51 -0700 > From: Xin LI > > Hi, > > On 2010/03/18 08:33, Kevin Oberman wrote: > > Since the update of DPMS to support amd64 on March 2, it has broken > > rather badly on my ThinkPad T43 laptop. The problem showed up on > > 8-stable built on March 3 and is still present after an update to stable > > of March 17. > > > > When in vty text mode, after the idle normal delay, the display blanks, > > but the backlight remains on, so the P in DPMS seems to be less than > > effective. At that point, the non-graphics display is dead. It never > > comes back when characters are entered. I can't get the display to come > > back without a reboot. > > > > I can, however, start X (and Gnome) and everything is fine. But > > switching back to any vty results in a blank screen. > > > > Any idea what happened and if there is a fix or workaround? Any data I > > can collect? > > > > The system is a uniprocessor Pentium-M: > > CPU: Intel(R) Pentium(R) M processor 2.00GHz (1995.01-MHz 686-class CPU) > > Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 > > > > Features=0xafe9fbff > Features2=0x180 > > AMD Features=0x10 > > > > My display is: > > vgap...@pci0:1:0:0: class=0x03 card=0x056e1014 chip=0x54601002 > > rev=0x00 hdr=0x00 > > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > > device = 'Radeon X300 Mobility (M22) (RV370)' > > class = display > > subclass = VGA > > Looks like that the CPU runs on i386 mode (doesn't support amd64?) and > when the screen was blank (with back light) the kernel is still alive > (as you can switch to X? > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve!Live free or die Yes, i386 only. (Pentium-M) and the system is fully functional. I can enter commands (very carefully) and they run. I can do 'startx' and gnome starts up correctly and the display works for X, but CTRL-ALT-F1 gives me a blank display until I re-boot. I can exit Gnome and blindly enter "shutdown -r now" and the system reboots as normal. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.2-p7 -> 8-STABLE mergemaster core dump
On Thu, Mar 18, 2010 at 5:27 PM, Jorge Biquez wrote: > Hello all. > With all respect Doug, users that have remote machines and do not have > access to it to boot single user like the manual says.. what can we do? I > understand that step is to be sure that no user will modify something while > we are doing those process. In my case I do that step after midnight when > our users are not in the server. > > Can others with remote systems comment about what they do in this step? > > Thanks in advance > > Jorge Biquez > > Hi Jorge As I mentioned in my email, the critical thing is that you must be running your new kernel before installing your new world. The single-user phase is simply to ensure that nothing is running that would interfere with the installworld/mergemaster steps. Therefore, an appropriate workaround if you cannot go to single user mode remotely would be to install the kernel, reboot into the new kernel, install world, reboot into the new world. However, if you have no remote access at all (remote power would be better than nothing!) this would be quite risky. Judicious use of nextboot, and having someone on standby who can find the power button is recommended. Cheers Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.2-p7 -> 8-STABLE mergemaster core dump
On Thu, Mar 18, 2010 at 11:27:48AM -0600, Jorge Biquez wrote: > At 01:55 a.m. 18/03/2010, Doug Barton wrote: > >On Wed, 17 Mar 2010, Cristiano Deana wrote: > > > >>yes, i knew. > >>but i was updating via ssh, so forget "run in single user". i also > >>know the exact procedure, but i upgrade hundreds of times before today > >>making this procedure and always went fine. > > > >So, it works just fine right up until the time it doesn't work. > >Feel free to deviate from the documented procedures, it's your > >system. Just don't be surprised if things break. > > > > > >Doug > >___ > > > Hello all. > With all respect Doug, users that have remote machines and do not > have access to it to boot single user like the manual says.. what > can we do? I understand that step is to be sure that no user will > modify something while we are doing those process. In my case I do > that step after midnight when our users are not in the server. > > Can others with remote systems comment about what they do in this step? Serial console. -- | Jeremy Chadwick j...@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 "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.2-p7 -> 8-STABLE mergemaster core dump
On Thu, Mar 18, 2010 at 12:27 PM, Jorge Biquez wrote: > Hello all. > With all respect Doug, users that have remote machines and do not have > access to it to boot single user like the manual says.. what can we do? I > understand that step is to be sure that no user will modify something while > we are doing those process. In my case I do that step after midnight when > our users are not in the server. > > Can others with remote systems comment about what they do in this step? > > Thanks in advance > KVM over IP or have someone onsite who is at least able to follow instructions and trusted eg datacenter personel(Some offer a "helping hands" type of program). KVM over IP is much preferred. Your KVM should be plugged into a power strip capable of remote management in case it flakes out(the ones I've used all do occasionally) so can be power cycled. -- Adam Vande More ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.2-p7 -> 8-STABLE mergemaster core dump
At 01:55 a.m. 18/03/2010, Doug Barton wrote: On Wed, 17 Mar 2010, Cristiano Deana wrote: yes, i knew. but i was updating via ssh, so forget "run in single user". i also know the exact procedure, but i upgrade hundreds of times before today making this procedure and always went fine. So, it works just fine right up until the time it doesn't work. Feel free to deviate from the documented procedures, it's your system. Just don't be surprised if things break. Doug ___ Hello all. With all respect Doug, users that have remote machines and do not have access to it to boot single user like the manual says.. what can we do? I understand that step is to be sure that no user will modify something while we are doing those process. In my case I do that step after midnight when our users are not in the server. Can others with remote systems comment about what they do in this step? Thanks in advance Jorge Biquez ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: DPMS broken on ThinkPad T43 since update for amd64 support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 2010/03/18 08:33, Kevin Oberman wrote: > Since the update of DPMS to support amd64 on March 2, it has broken > rather badly on my ThinkPad T43 laptop. The problem showed up on > 8-stable built on March 3 and is still present after an update to stable > of March 17. > > When in vty text mode, after the idle normal delay, the display blanks, > but the backlight remains on, so the P in DPMS seems to be less than > effective. At that point, the non-graphics display is dead. It never > comes back when characters are entered. I can't get the display to come > back without a reboot. > > I can, however, start X (and Gnome) and everything is fine. But > switching back to any vty results in a blank screen. > > Any idea what happened and if there is a fix or workaround? Any data I > can collect? > > The system is a uniprocessor Pentium-M: > CPU: Intel(R) Pentium(R) M processor 2.00GHz (1995.01-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 > > Features=0xafe9fbff Features2=0x180 > AMD Features=0x10 > > My display is: > vgap...@pci0:1:0:0: class=0x03 card=0x056e1014 chip=0x54601002 > rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'Radeon X300 Mobility (M22) (RV370)' > class = display > subclass = VGA Looks like that the CPU runs on i386 mode (doesn't support amd64?) and when the screen was blank (with back light) the kernel is still alive (as you can switch to X? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLolx/AAoJEATO+BI/yjfB64UIAKxCMzcVfSoKugbL7xq5PkRC Q7t8XwroLBbyk2R8RqDhxR6Cz4GgnEPvlhEBf0Rbvbo3mSDwhl1P1AXXVCq/NO83 dMuzZORRgjHBsWWn2PF+L+x6VmiNgJBtmhjW0lLo0f8nDbykKFmFWDCV5cE7QCfE +6g1FxB3HVMpqyisWyOG6pZ2wAv1kSX6B+XXewrhXA/Zn3q/XUabFpzMXPHlGWZc tlWqhY2TXSQULgCq9Be4ZCqrZnfmK1vf2JHxEfUHR8wNJMPIRxrypu40wgGZHiR7 4P5k8tjysF+ql5pqFyG/X8Y43TJAdK+mXatMp4HRnefjduBVkY1hd8lP/14/AB0= =NVr/ -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
DPMS broken on ThinkPad T43 since update for amd64 support
Since the update of DPMS to support amd64 on March 2, it has broken rather badly on my ThinkPad T43 laptop. The problem showed up on 8-stable built on March 3 and is still present after an update to stable of March 17. When in vty text mode, after the idle normal delay, the display blanks, but the backlight remains on, so the P in DPMS seems to be less than effective. At that point, the non-graphics display is dead. It never comes back when characters are entered. I can't get the display to come back without a reboot. I can, however, start X (and Gnome) and everything is fine. But switching back to any vty results in a blank screen. Any idea what happened and if there is a fix or workaround? Any data I can collect? The system is a uniprocessor Pentium-M: CPU: Intel(R) Pentium(R) M processor 2.00GHz (1995.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 Features=0xafe9fbff AMD Features=0x10 My display is: vgap...@pci0:1:0:0: class=0x03 card=0x056e1014 chip=0x54601002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'Radeon X300 Mobility (M22) (RV370)' class = display subclass = VGA -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: loader(8) readin failed on 7.2R and later including 8.0R
On Thursday 18 March 2010 7:10:59 am Carsten Bäcker wrote: > Hello, > > i ran into a similar problem when recently trying to install 8.0R on an > embedded system. We've been using this hardware for a couple of > years with FreeBSD 4.11 and didn't see any problem like this. > > Disabling the memory hole (15-16M) solved the problem here, but > that shouldn't be a solution. I wonder whether it's a loader-, or a > BIOS-problem, since memory-allocation should respect reserved > areas. The problem is likely because an 8.0 kernel is simply larger than a 4.11 kernel. 4.11's loader would have had the same issue. The problem (as it were), is that we expect to be able to load the kernel + modules into one contiguous chunk of RAM, starting at 4MB (PAE and amd64 kernels start at 2MB). > Best regards > Carsten Bäcker > > > On Sunday 06 December 2009 12:16:36 am Hiroki Sato wrote: > > Hiroki Sato wrote > >in<20091205.184250.201700943@allbsd.org>: > > > > hr> A summary so far is: > > hr> > > hr> 1) a<8MB 7.1R kernel + stock 8.0R loader > > hr> 2a) a>8MB 8.0R kernel + stock 8.0R loader > > hr> 2b) a>8MB 8.0R kernel + 8.0R loader with LOADER_NO_GPT_SUPPORT=yes > > hr> 2c) a>8MB 8.0R kernel + loader with your patch > > hr> 3a) a<8MB 8.0R kernel + stock 8.0R loader > > hr> 3b) a<8MB 8.0R kernel + 8.0R loader with LOADER_NO_GPT_SUPPORT=yes > > hr> 3c) a<8MB 8.0R kernel + loader with your patch > > > > Grr, I double-checked how it got stuck, then I found the console > > redirect was disabled because of an old device.hints. The revised > > summary is: > > > > loading text loading syms boot > >1) OKOK OK > >2a) "readin failed" - - > >2b) OK"skipped!" OK > >2c) OK"skipped!" OK > >3a) OKOK OK > >3b) OKOK OK > >3c) OKOK OK > > > > So, the case 2c shows that your patch solves the problem in the case > > 2a. Thank you! :) > > > > Loading>8MB kernel works now, but loading syms sections still fails > > even in the case 2c. > > Ok. Your system's SMAP is kind of weird (it has a very small region above > 1MB, so it may not deal well with "large" kernels, though I thought it had > enough room for at least a 12MB kernel. Hmm, the size of the kernel file may > be deceptive though since it does not include BSS. I wonder if it is trying > to load the symbols after the BSS. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: loader(8) readin failed on 7.2R and later including 8.0R
on 18/03/2010 13:10 Carsten Bäcker said the following: > Hello, > > i ran into a similar problem when recently trying to install 8.0R on an > embedded system. We've been using this hardware for a couple of > years with FreeBSD 4.11 and didn't see any problem like this. > > Disabling the memory hole (15-16M) solved the problem here, but > that shouldn't be a solution. I wonder whether it's a loader-, or a > BIOS-problem, since memory-allocation should respect reserved > areas. True. Please also keep in mind that BIOS should report reserved areas correctly too. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: loader(8) readin failed on 7.2R and later including 8.0R
Hello, i ran into a similar problem when recently trying to install 8.0R on an embedded system. We've been using this hardware for a couple of years with FreeBSD 4.11 and didn't see any problem like this. Disabling the memory hole (15-16M) solved the problem here, but that shouldn't be a solution. I wonder whether it's a loader-, or a BIOS-problem, since memory-allocation should respect reserved areas. Best regards Carsten Bäcker On Sunday 06 December 2009 12:16:36 am Hiroki Sato wrote: Hiroki Sato wrote in<20091205.184250.201700943@allbsd.org>: hr> A summary so far is: hr> hr> 1) a<8MB 7.1R kernel + stock 8.0R loader hr> 2a) a>8MB 8.0R kernel + stock 8.0R loader hr> 2b) a>8MB 8.0R kernel + 8.0R loader with LOADER_NO_GPT_SUPPORT=yes hr> 2c) a>8MB 8.0R kernel + loader with your patch hr> 3a) a<8MB 8.0R kernel + stock 8.0R loader hr> 3b) a<8MB 8.0R kernel + 8.0R loader with LOADER_NO_GPT_SUPPORT=yes hr> 3c) a<8MB 8.0R kernel + loader with your patch Grr, I double-checked how it got stuck, then I found the console redirect was disabled because of an old device.hints. The revised summary is: loading text loading syms boot 1) OKOK OK 2a) "readin failed" - - 2b) OK"skipped!" OK 2c) OK"skipped!" OK 3a) OKOK OK 3b) OKOK OK 3c) OKOK OK So, the case 2c shows that your patch solves the problem in the case 2a. Thank you! :) Loading>8MB kernel works now, but loading syms sections still fails even in the case 2c. Ok. Your system's SMAP is kind of weird (it has a very small region above 1MB, so it may not deal well with "large" kernels, though I thought it had enough room for at least a 12MB kernel. Hmm, the size of the kernel file may be deceptive though since it does not include BSS. I wonder if it is trying to load the symbols after the BSS. -- John Baldwin __ -- *** *demig Prozessautomatisierung GmbH * demig Anlagentechnik GmbH * * * * * Anschrift: Haardtstrasse 40 * Haardtstrasse 40 * * D-57076 Siegen * D-57076 Siegen * * Registergericht: Siegen HRB 2819 * Siegen HRB 5532* * Geschaeftsfuehrer: Joachim Herbst, * Joachim Herbst,* *Winfried Held * Winfried Held * * Telefon: +49 271 772020 * +49 271 772020 * * Telefax: +49 271 74704 * +49 271 74704 * * E-Mail:i...@demig.de * a...@demig.de* * http://www.demig.de * http://www.demig.de* *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.2-p7 -> 8-STABLE mergemaster core dump
On Wed, 17 Mar 2010, Cristiano Deana wrote: yes, i knew. but i was updating via ssh, so forget "run in single user". i also know the exact procedure, but i upgrade hundreds of times before today making this procedure and always went fine. So, it works just fine right up until the time it doesn't work. Feel free to deviate from the documented procedures, it's your system. Just don't be surprised if things break. Doug ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
