From owner-freebsd-amd64@FreeBSD.ORG Sat Dec 2 23:20:45 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA04B16A415; Sat, 2 Dec 2006 23:20:45 +0000 (UTC) (envelope-from bsam@bsam.ru) Received: from mail.kuban.ru (mail.kuban.ru [62.183.66.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3301543CC0; Sat, 2 Dec 2006 23:20:18 +0000 (GMT) (envelope-from bsam@bsam.ru) Received: from bsam.ru ([83.239.48.150]) by mail.kuban.ru (8.9.1/8.9.1) with ESMTP id kB2NKGQS061352; Sun, 3 Dec 2006 02:20:30 +0300 (MSK) Received: from bsam by bsam.ru with local (Exim 4.62 (FreeBSD)) (envelope-from ) id 1Gqe7o-0000DK-V1; Sun, 03 Dec 2006 02:18:28 +0300 To: Alexander Leidinger References: <20061202160740.55046cc3@Magellan.Leidinger.net> <68623948@bsam.ru> From: Boris Samorodov Date: Sun, 03 Dec 2006 02:18:28 +0300 In-Reply-To: <68623948@bsam.ru> (Boris Samorodov's message of "Sat, 02 Dec 2006 22:40:51 +0300") Message-ID: <15016603_-_@bsam.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Boris Samorodov Cc: amd64@freebsd.org, current@freebsd.org Subject: [panic] Re: small heads-up: Syncing amd64 GENERIC with i386 GENERIC (removing LINUX stuff) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Dec 2006 23:20:45 -0000 On Sat, 02 Dec 2006 22:40:51 +0300 Boris Samorodov wrote: > On Sat, 2 Dec 2006 16:07:40 +0100 Alexander Leidinger wrote: > > the linux module is now usable on amd64 (thanks to kib@ and his commit > > to the kernel linker in HEAD). > Cvsupped a couple of hours ago my amd64-current, rebuilt/reinstalled > world/kernel. The kernel is GENERIC without COMPAT_LINUX32, LINPROCFS, > LINSYSFS. But linux.ko hadn't been built. Should I cvsup once more or > did I miss something? > I'd tested kib@ patches (about two weeks ago) and noticed that linux > kernel module can't be unloaded _after_ mounting/unmounting linprocfs, > linsysfs or linux devfs. Can anybody confirm? OK, after cvsup and rebuild/install kernel I do: # kldload linux # kldload linsysfs # kldunload linsysfs and get a reprodusable panic: ----- Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0xffffffffa33a2584 stack pointer = 0x10:0xffffffffa0ff4a50 frame pointer = 0x10:0xffffffffa0ff4a70 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 717 (kldunload) panic: from debugger cpuid = 0 Uptime: 35s Physical memory: 1012 MB Dumping 155 MB: 140 124 108 92 76 60 44 28 12 #0 doadump () at pcpu.h:172 172 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) where #0 doadump () at pcpu.h:172 #1 0xffffffff8043c3e9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:411 #2 0xffffffff8043be7b in panic (fmt=0xffffffff8069d087 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:567 #3 0xffffffff801acd87 in db_panic (addr=0, have_addr=0, count=0, modif=0x0) at /usr/src/sys/ddb/db_command.c:433 #4 0xffffffff801ad229 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401 #5 0xffffffff801af133 in db_trap (type=-1593882688, code=0) at /usr/src/sys/ddb/db_main.c:222 #6 0xffffffff804624f8 in kdb_trap (type=9, code=0, tf=0xffffffffa0ff49a0) at /usr/src/sys/kern/subr_kdb.c:502 #7 0xffffffff8064abd1 in trap_fatal (frame=0xffffffffa0ff49a0, eva=18446742975218145296) at /usr/src/sys/amd64/amd64/trap.c:692 #8 0xffffffff8064b191 in trap (frame= {tf_rdi = -2137684416, tf_rsi = -1098491406320, tf_rdx = 0, tf_rcx = 683, tf_r8 = -2140136456, tf_r9 = -1098491406320, tf_rax = 0, tf_rbx = -2401050962867404578, tf_rbp = -1593882000, tf_r10 = 0, tf_r11 = 0, tf_r12 = -1556469664, tf_r13 = -1098768417664, tf_r14 = 0, tf_r15 = 0, tf_trapno = 9, tf_addr = 0, tf_flags = -2143094431, tf_err = 0, tf_rip = -1556470396, tf_cs = 8, tf_rflags = 66182, tf_rsp = -1593882016, tf_ss = 16}) at /usr/src/sys/amd64/amd64/trap.c:500 #9 0xffffffff8063309b in calltrap () at /usr/src/sys/amd64/amd64/exception.S:168 #10 0xffffffffa33a2584 in ?? () #11 0xffffffffa33a2860 in ?? () #12 0xffffffffa33a2860 in ?? () #13 0xffffffffa0ff4aa0 in ?? () #14 0xffffffff804a692e in vfs_modevent (mod=0xffffffff80958640, type=1020221456, data=0xffffffffa33a2860) at /usr/src/sys/kern/vfs_init.c:257 (kgdb) ----- WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve