Re: mounting uzip image: Invalid argument
Kris Kennaway wrote:
On Mon, Dec 25, 2006 at 11:17:21PM +0200, Erik Udo wrote:
I'm making a live cd and i just hit a wall with uzip.
I started by creating a null 1GB file, which i filled with FreeBSD.
After that i compressed the file with mkuzip.
Any attempts to mount this compressed image has failed, here is the
output of truss when using mount_cd9660 to mount the image:
koti# truss mount_cd9660 /dev/md0.uzip testi
lstat("/stor/livecd/testi",0xbfbfe390) = 0 (0x0)
stat("/stor/livecd/testi",0xbfbfe420)= 0 (0x0)
open("/dev/md0.uzip",0x0,00) = 3 (0x3)
ioctl(3,CHIOGPICKER,0xbfbfe15c) ERR#25 'Inappropriate
ioctl for device'
Looks like you don't have geom_uzip configured, per the manpage.
Kris
geom_uzip configured? I have it loaded in the kernel. Anyway, i solved
it by "mount -o to /dev/md0.uzip testi", i didn't need to mount it with
mount_cd9660.
Perhaps the man page is wrong?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.1-RELEASE / 6.2 Kernel Crash...
On Wednesday 27 December 2006 02:24, Jan Knepper wrote: > Tried that and started > > dd if=/dev/ad4 if=/dev/ad6 bs=1m > > Kernel went in panic and automatic reboot in about an hour... > > It gets worse... when it does reboot the disk drive will not show in the > BIOS, nor does FreeBSD recognize it during boot. The system actually has > to be turned off to reset the drive... > > This is bad... > > Any other suggestions? > Maybe you can setup a serial console to grab the panic message? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.1-RELEASE / 6.2 Kernel Crash...
Hans Petter Selasky wrote: On Wednesday 27 December 2006 02:24, Jan Knepper wrote: Tried that and started dd if=/dev/ad4 if=/dev/ad6 bs=1m Kernel went in panic and automatic reboot in about an hour... Does it reproducable while invoking dd with the input device as if=/dev/ad4s1a or using your drives' slice and partition? And the "of=" too. -- Best regards, Illia Baidakov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.1-RELEASE / 6.2 Kernel Crash...
FreeBSD 5.x branch run on that machine for almost 2 years without a problem and magically the same time period in *hours* that I upgrade the machine I get hardware problems too? Not an impossible coincidence, but not very likely... Thanks! Jan Mario Theodoridis wrote: is it just me, or is this beginning to sound like hardware problems? mario;> On Tuesday 26 December 2006 17:24, Jan Knepper wrote: Tried that and started dd if=/dev/ad4 if=/dev/ad6 bs=1m Kernel went in panic and automatic reboot in about an hour... It gets worse... when it does reboot the disk drive will not show in the BIOS, nor does FreeBSD recognize it during boot. The system actually has to be turned off to reset the drive... This is bad... Any other suggestions? Thanks! Jan Tim McCullagh wrote: Hi Jan try editing your loader.conf I had a similar sounding issue. As soon as I did the following the system became stable immediately. It was also on a Tyan Mainboard, although with dual Xeon's # vi /boot/loader.conf hint.apic.0.disabled="1" Regards Tim - Original Message - From: "Jan Knepper" <[EMAIL PROTECTED]> To: "FreeBSD ISP" <[EMAIL PROTECTED]>; "FreeBSD Hackers" Sent: Wednesday, December 27, 2006 7:09 AM Subject: 6.1-RELEASE / 6.2 Kernel Crash... All, (sorry for the cross post) Something goofy is going on with a 6.x kernel. Dual Opteron Server (Tyan motherboard). 2 GB RAM... 2 x 256 GB SATA HD's. Just upgraded this machine from FreeBSD 5.5-STABLE to 6.2RC# and than down to 6.1-RELEASE. For some reason FreeBSD 6.1 seems to be very unstable. I use a custom kernel, (most devices not present in the system have been removed). When I create an SMP kernel after an undefined about of time which I have seen varying from 5 minutes up to about 6 hours the kernel will just hang. Things that seem to accelerate/aggrevate this are running CVSup from a repository on the same system. Something else that seems to push it is dd if=/dev/ad4 if=/dev/ad6 bs=64m (copying the master disk to the supposed slave, however geom is not active and module geom_mirror is not loaded! When I take SMP out of the kernel config and rebuild and install instead of hanging, the system seems to crash and reboot when I perform the same action. Also... When I first upgraded I did get an error during boot: kernel: module_register_init: MOD_LOAD (amr_linux, 0x805db120, 0) error 6 I disabled device amr (under RAID controllers) in the kernel config which took care of this. Following the bootlog. If any of you had any idea what the problem might be I definitely would like to know. Thanks! Jan syslogd: kernel boot file is /boot/kernel/kernel kernel: Copyright (c) 1992-2006 The FreeBSD Project. kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 kernel: The Regents of the University of California. All rights reserved. kernel: FreeBSD 6.1-RELEASE #4: Tue Dec 26 12:03:35 EST 2006 kernel: [EMAIL PROTECTED]:/usr/src/sys/amd64/compile/digitaldaemon kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 kernel: CPU: AMD Opteron(tm) Processor 246 (1993.53-MHz K8-class CPU) kernel: Origin = "AuthenticAMD" Id = 0xf5a Stepping = 10 kernel: Features=0x78bfbff kernel: AMD Features=0xe0500800 kernel: real memory = 2147418112 (2047 MB) kernel: avail memory = 2065596416 (1969 MB) kernel: ACPI APIC Table: kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs kernel: cpu0 (BSP): APIC ID: 0 kernel: cpu1 (AP): APIC ID: 1 kernel: MADT: Forcing active-low polarity and level trigger for SCI kernel: ioapic0 irqs 0-23 on motherboard kernel: ioapic1 irqs 24-27 on motherboard kernel: ioapic2 irqs 28-31 on motherboard kernel: netsmb_dev: loaded kernel: acpi0: on motherboard kernel: acpi0: Power Button (fixed) kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x5008-0x500b on acpi0 kernel: cpu0: on acpi0 kernel: acpi_throttle0: on cpu0 kernel: cpu1: on acpi0 kernel: pcib0: port 0xcf8-0xcff on acpi0 kernel: pci0: on pcib0 kernel: pcib1: at device 6.0 on pci0 kernel: pci3: on pcib1 kernel: ohci0: mem 0xff3fd000-0xff3fdfff irq 19 at device 0.0 on pci3 kernel: ohci0: [GIANT-LOCKED] kernel: usb0: OHCI version 1.0, legacy support kernel: usb0: on ohci0 kernel: usb0: USB revision 1.0 kernel: uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 kernel: uhub0: 3 ports with 3 removable, self powered kernel: ohci1: mem 0xff3fe000-0xff3fefff irq 19 at device 0.1 on pci3 kernel: ohci1: [GIANT-LOCKED] kernel: usb1: OHCI version 1.0, legacy support kernel: usb1: on ohci1 kernel: usb1: USB revision 1.0 kernel: uhub1: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 kernel: uhub1: 3 ports with 3 removable, self powered kernel: xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0x8080-0x80ff mem 0xff3ff800-0xff3ff87f irq 16 at device 10.0 on pci3 kernel: miibus0: on xl0 kernel: ukphy0: on miibus0 kernel: ukphy0: 10baseT, 10b
Re: 6.1-RELEASE / 6.2 Kernel Crash...
Kris Kennaway wrote: On Tue, Dec 26, 2006 at 08:24:12PM -0500, Jan Knepper wrote: Tried that and started dd if=/dev/ad4 if=/dev/ad6 bs=1m Kernel went in panic and automatic reboot in about an hour... It gets worse... when it does reboot the disk drive will not show in the BIOS, nor does FreeBSD recognize it during boot. The system actually has to be turned off to reset the drive... This is bad... Any other suggestions? Sounds like a bug in the support for your ATA hardware, or your hardware is broken. The very least you'll need to do is to obtain a crashdump and debugging backtrace (see the developers handbook) and CC it to sos@ Will start working on that (or downgrade to 5.5)... I am testing that and I think although I have not found a documented way of doing that it can be done. Thanks! Jan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.1-RELEASE / 6.2 Kernel Crash...
Hans Petter Selasky wrote: On Wednesday 27 December 2006 02:24, Jan Knepper wrote: Tried that and started dd if=/dev/ad4 if=/dev/ad6 bs=1m Kernel went in panic and automatic reboot in about an hour... It gets worse... when it does reboot the disk drive will not show in the BIOS, nor does FreeBSD recognize it during boot. The system actually has to be turned off to reset the drive... This is bad... Any other suggestions? Maybe you can setup a serial console to grab the panic message? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html Good idea... I might just try that... Thanks! Jan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Init.c, making it chroot
How can i make init chroot after executing /etc/rc, and executing /etc/rc again in the chrooted enviroment? For this to work, i'd like to know at what point do i call chroot(), becouse init.c uses fork() at the point where it runs the rc script. The thing is, i want to run a whole system in a chrooted enviroment in this livecd i'm making. But the command "chroot /mnt/root /etc/rc" returns after the /etc/rc has been run, dropping me back from the chrooted enviroment. And if it doesn't, init never starts the multiuser mode. So how can i go to the multiuser mode in a chrooted enviroment? I guess the only way to do that is to modify init.c Any help/feedback is appreciated. Cheers, Erik ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.1-RELEASE / 6.2 Kernel Crash...
In <[EMAIL PROTECTED]>, Jan Knepper <[EMAIL PROTECTED]> typed: > FreeBSD 5.x branch run on that machine for almost 2 years without a > problem and magically the same time period in *hours* that I upgrade the > machine I get hardware problems too? Not an impossible coincidence, but > not very likely... Or it could be that you have a hardware problem in hardware that wasn't used by 5.x but is by 6.x. I had an 11/750 that ran BSD 4.2 for years with no problems. When I tried to upgrade it to BSD 4.3, it would reliably panic in namei during the boot process. We had about a dozen 750s, and this was our test machine - so none of them were going to be upgraded until this got fixed, deadline or no. Stepping through namei in the debugger showed that one of the instructions in the function prelude was changing a high bit in a register it wasn't supposed to touch at all. In 4.2, the register was unused, because namei got passed a handful of arguments. In 4.3, it got passed a pointer to a struct with some of that information in it, and the pointer wound up in said register. Dereferencing the pointer caused the panic. A motherboard replacement solved the problem. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.1-RELEASE / 6.2 Kernel Crash...
Understood... and exactly as I wrote... Not impossible, but not that likely... Thanks! Jan Mike Meyer wrote: In <[EMAIL PROTECTED]>, Jan Knepper <[EMAIL PROTECTED]> typed: FreeBSD 5.x branch run on that machine for almost 2 years without a problem and magically the same time period in *hours* that I upgrade the machine I get hardware problems too? Not an impossible coincidence, but not very likely... Or it could be that you have a hardware problem in hardware that wasn't used by 5.x but is by 6.x. I had an 11/750 that ran BSD 4.2 for years with no problems. When I tried to upgrade it to BSD 4.3, it would reliably panic in namei during the boot process. We had about a dozen 750s, and this was our test machine - so none of them were going to be upgraded until this got fixed, deadline or no. Stepping through namei in the debugger showed that one of the instructions in the function prelude was changing a high bit in a register it wasn't supposed to touch at all. In 4.2, the register was unused, because namei got passed a handful of arguments. In 4.3, it got passed a pointer to a struct with some of that information in it, and the pointer wound up in said register. Dereferencing the pointer caused the panic. A motherboard replacement solved the problem. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Init.c, making it chroot
On Wed, Dec 27, 2006 at 09:27:24PM +0200, Erik Udo wrote: > How can i make init chroot after executing /etc/rc, and executing > /etc/rc again in the chrooted enviroment? > Go look at the NetBSD init(8) that can do this, and bring us back a patch for this. Quote from the NetBSD init(8) manpage: : 2. Multi-user boot (default operation). Executes /etc/rc (see rc(8)). : If this was the first state entered (as opposed to entering here : after state 1), then /etc/rc will be invoked with its first argument : being `autoboot'. If /etc/rc exits with a non-zero (error) exit : code, commence single user operation by giving the super-user a : shell on the console by going to state 1 (single user). Otherwise, : proceed to state 3. : : If value of the ``init.root'' sysctl node is not equal to / at this : point, the /etc/rc process will be run inside a chroot(2) indicated : by sysctl with the same error handling as above. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpO7LdxYof4f.pgp Description: PGP signature
Re: 6.1-RELEASE / 6.2 Kernel Crash...
On Wed, 27 Dec 2006, Mike Meyer wrote: > I had an 11/750 that ran BSD 4.2 for years with no problems. When I > tried to upgrade it to BSD 4.3, it would reliably panic in namei during > the boot process. We had about a dozen 750s, and this was our test > machine - so none of them were going to be upgraded until this got > fixed, deadline or no. Heh. We had a PDP-11/40 running Edition 6, and it was unable to use the "overlapped seeks" feature of the RK-11 controller, so of course Unix got blamed by DEC. Turned out that DEC OSs (RSX, RSTS etc) never used that feature, and an FCO was necessary to fix it. -- Dave ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.1-RELEASE / 6.2 Kernel Crash...
[Attempting to redirect this to -stable, where it's more appropriate.] Jan Knepper wrote: > FreeBSD 5.x branch run on that machine for almost 2 years without a > problem and magically the same time period in *hours* that I upgrade the > machine I get hardware problems too? Not an impossible coincidence, but > not very likely... Depends on how you did the upgrade. Was the machine running continuously for 2 years, then you turned it off, then you did the upgrade? I had a box die that way because (we found out later) that the system drive's spindle had "issues" that were not apparent until it had been turned off, cooled down, then spun (sort of) back up. IOW, you're probably right, but "magical" hardware problems that develop during upgrade periods are more common than a lot of people realize. Meanwhile, back at the ranch, if you can't easily get a serial console up and running, your earlier suggestion of putting the box back to the last known good 5.x release is a good one. At least that can help rule out hardware _failure_, as opposed to hardware-used-differently issues. hth, Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
unresolved symbol for C++ class dtor
hello
i've written a testprogram to check how dynamic linking
works for C++ code, specially for class, when are global objects'
ctors and dtors are being called etc.
however, i've run into a very strange problem.
in the main program i have a "class module", which has
a virtual destructor. The dlopen()'d module has a class
derived from this one.
Main program:
class module {
public:
module();
virtual ~module();
};
mod_bar:
class modbar: public module {
public:
modbar(): module() {};
~modbar() {};
};
Of course the main program's module class's methods are
not just declared they are also defined elsewhere.
This is the way i try to dlopen() mod_bar:
if ( !(dh = dlopen(MOD_BAR, RTLD_NOW|RTLD_GLOBAL)) ) {
...
}
i've got the following error message when running the code:
Unable to dlopen(lib/mod_bar.so): lib/mod_bar.so: Undefined symbol
"_ZN6moduleD2Ev"
however, i've check the testprogram:
$ nm bin/dltest | grep _ZN6moduleD2Ev
08048918 T _ZN6moduleD2Ev
so it does exist.
i've tried to compile the binaries both without and without -fpic -fPIC,
but nothing had changed.
the question is, what am i doing wrong? according to the symbols,
the dynamic linker should be able to load that symbol, however it doesn't.
what do i need to do to fix this?
looking forward for answers,
Bye,
Gergely Czuczy
mailto: [EMAIL PROTECTED]
--
Weenies test. Geniuses solve problems that arise.
pgpPWpOXijve2.pgp
Description: PGP signature
Re: unresolved symbol for C++ class dtor
On Wed, 27 Dec 2006 18:09:41 +0100 Gergely CZUCZY <[EMAIL PROTECTED]> wrote: Executables only export symbols required by shared libraries known at link time by default. You want --export-dynamic on linker command line or ether -rdynamic or -Wl,--export-dynamic on CC command line. -- Alexander Kabaev signature.asc Description: PGP signature
Re: 6.1-RELEASE / 6.2 Kernel Crash...
Kris Kennaway wrote: On Tue, Dec 26, 2006 at 08:24:12PM -0500, Jan Knepper wrote: Tried that and started dd if=/dev/ad4 if=/dev/ad6 bs=1m Kernel went in panic and automatic reboot in about an hour... It gets worse... when it does reboot the disk drive will not show in the BIOS, nor does FreeBSD recognize it during boot. The system actually has to be turned off to reset the drive... This is bad... Any other suggestions? Sounds like a bug in the support for your ATA hardware, or your hardware is broken. The very least you'll need to do is to obtain a crashdump and debugging backtrace (see the developers handbook) and CC it to sos@ This is getting funnier... I added: dumpdev="AUTO" to: rc.conf Rebooted the system and tried to get it to crash again... And indeed it does in process 9: taskq Then it starts dumping which takes a couple of seconds as the machine has 2 GB Ram... Than it reboots... and the next thing you know... savecore does NOT recognize a dump on the swap file system. If does not save anything to /var/crash... Tried this about 10 times... No luck... Any other idea's? Thanks! Jan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel hang on 6.x
On Thursday 14 December 2006 16:06, R. Tyler Ballance wrote: > > On Dec 14, 2006, at 1:05 PM, Brian Dean wrote: > > > Hi, > > > > We're experiencing a kernel hang on a 6.x quad processor Sun amd64 > > based system. We are able to reproduce it fairly reliably, but the > > environment to do so is not easily replicatable so I cannot provide a > > simple test case. However, I have been able to build a debug kernel > > and when the system "hangs", I can break to the debugger prompt. But > > once there, I'm not sure what to do to isolate where the system is > > hung up. I have confirmed that the hang occurs in both SMP and > > uniprocessor mode. Here are some system details: > > > I think you'll need to ship this machine to my house for further > umerm, diagnostics, yes, that's it ;) > > > On a more serious topic, can you paste the output from: > > > ddb> show pcpu > ddb>allpcpu > ddb>traceall > ddb>show alllocks > ddb>show lockedvnods > > Just curious as to whether those would show more info, because you're > right, that trace is about as informative as new printer paper :) The 'traceall' seemed to miss several threads actually (like pid 18). Can you get a 'ps'? Also, are you able to get a kernel dump when this happens? -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
