Re: "Could not allocate I/O space" and "intsmb0 attach returned 6" in a under-Hyper-V context on Ryzen Threadripper: Is this expected?
On Sunday, April 01, 2018 02:23:36 PM Mark Millard wrote: > For: > > # uname -apKU > FreeBSD FBSDHUGE 12.0-CURRENT FreeBSD 12.0-CURRENT r331831M amd64 amd64 > 1200060 1200060 > > I get: > > . . . > pci0: at device 7.3 (no driver attached) > . . . > intsmb0: at device 7.3 on pci0 > intsmb0: Could not allocate I/O space > device_attach: intsmb0 attach returned 6 > > on a Ryzen Threadripper 1950X where FreeBSD is being run under > Hyper-V (on a Windows 10 Pro machine). > > Is this expected? Did I misconfigure something in Hyper-V? That seems like an odd device to have for an AMD machine. I suspect that this has never worked and the module started auto-loading due to devmatch. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: PAT and identity mapped pages.
On Friday, November 20, 2015 11:14:57 AM AlexandreFressange wrote: > Hi, > > On x86_64, every memory page entry has a bit (4) to control its cache method: > write-back or write-through. > > But even on identity mapped pages, you still use paging. Say, I want a page > to be uncached; I can use the PAT to Uncached. > > In this case, what happens to the bit 4 of the accessed page? is it ignored? Can you clarify more what you mean by an identity mapped page? If you mean the direct map, the OS has to ensure that all mappings of a given physical page use the same PAT settings, so when a page is mapped with a non-default PAT setting the page entries for the direct map have to be updated as well as any other mappings. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: kernel timers and clocks
On Thursday, July 23, 2015 11:52:34 AM deco33...@yandex.com wrote: Hello, I am trying to figure out how timers work for the amd64 platform on freebsd 10. How the kernel manage the timers? is it using TSC? The kern.timecounter sysctl tree shows the available timercounters (and information about each one) as well as which one is currently being used. Note that timecounters are used to compute the uptime and time-of-day for get*time and *time as well as gettimeofday() and clock_gettime() in userland. There is another timer interface used to manage interval timers. This uses timer interrupts to terminate sleeps, and things like setitimer(), alarm(), etc. (also the timeouts for select(2) and poll(2), etc.). These can be examined via the kern.eventtimer sysctl tree. In some cases the same hardware can be used for both purposes, but not always. On x86 it is common to use the TSC for the timecounter and the local APIC timer for the event timer. I see lot of functions using getnanotime and friend but I don't get how they work. They just iterate over time and read a volatile value. Where/how is that value kept updated? Every so often an event timer interrupt triggers the tc_windup() function in kern_tc.c. That function updates the timehands structure used by getnanotime() and friends. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: memory type e820
On Saturday 01 November 2014 18:55:53 Sourish Mazumder wrote: Hi John, I tried the pmap_mapdev() as suggested by you. Works perfectly. Thanks for the information. Sure. What is required, If I want to add this nvram memory to VM pages? Hmm. If this is device memory you generally don't want that. I'm not actually sure how to do this at runtime. If you don't mind having a local hack you can add a change in the MD startup code (e.g. in hammer_time() in sys/amd64/amd64/machdep.c) to adjust the ranges added to phys_avail[] and dump_avail[]. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: memory type e820
On Thursday, October 30, 2014 1:56:00 am Sourish Mazumder wrote: I have nvram device in my system. I am able to detect the nvram device address by scanning the bios_smap. How do I add this new found nvram memory into kernel address space? Do you just want to map it so you can get a valid pointer or do you want it to be treated as normal memory by the VM system (i.e. available for use as pages in the VM page cache)? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: memory type e820
On Thursday, October 30, 2014 12:39:27 pm Sourish Mazumder wrote: Hi John, I want to make a block device out of this nvram memory. So, I will need to perform memcpy() operation into this memory. Do I need to add this memory into the vm system, if I need to do operations like memcpy(). Ah, so you just need to map it. The most expedient thing you can do for this is: void *p; p = pmap_mapdev(physaddr, len); (This uses an uncached mapping). When you are finished (e.g during a detach routine if you need to unload the driver) you can do: pmap_unmapdev((vm_offset_t)p, len); Note that for a PCI BAR you would do something different, but for a resource you discover via the SMAP and is x86 specific this is ok. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: memory type e820
On Wednesday, September 24, 2014 5:12:37 am Sourish Mazumder wrote: Hi, Does freebsd has a linux equivalent of the function e820_any_mapped() ? This function is used to scan the system memory for a specific type. How to scan the system memory in freebsd? There is not an equivalent function, no. There is phys_avail[] (memory pages available for the VM system to use, doesn't include some early allocations such as the message buffer) and dump_avail[] (all memory pages). What are you trying to scan for? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/189741: 9/STABLE panic at em_msix_rx w/ em(4) + PF
The following reply was made to PR amd64/189741; it has been noted by GNATS.
From: John Baldwin j...@freebsd.org
To: Nick Rogers ncrog...@gmail.com
Cc: freebsd-gnats-sub...@freebsd.org, Gleb Smirnoff gleb...@freebsd.org
Subject: Re: amd64/189741: 9/STABLE panic at em_msix_rx w/ em(4) + PF
Date: Sat, 17 May 2014 07:43:26 -0400
On 5/16/14, 10:51 AM, Nick Rogers wrote:
On Thu, May 15, 2014 at 4:32 AM, John Baldwin j...@freebsd.org wrote:
On 5/12/14, 7:43 PM, Nick Rogers wrote:
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 5; apic id = 05
fault virtual address = 0x10
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x8033d350
stack pointer= 0x28:0xff83545384b0
frame pointer= 0x28:0xff83545384c0
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 12 (irq262: em2:rx 0)
trap number = 12
panic: page fault
cpuid = 5
KDB: stack backtrace:
#0 0x80956836 at kdb_backtrace+0x66
#1 0x8091c40e at panic+0x1ce
#2 0x80d31e70 at trap_fatal+0x290
#3 0x80d321d1 at trap_pfault+0x211
#4 0x80d327d3 at trap+0x363
#5 0x80d1b9d3 at calltrap+0x8
#6 0x8034872d at pf_test_rule+0x17ed
#7 0x8034ba12 at pf_test+0x1032
#8 0x8035112b at pf_check_in+0x2b
#9 0x809e952e at pfil_run_hooks+0x9e
#10 0x80a5286a at ip_input+0x2ea
#11 0x809e8858 at netisr_dispatch_src+0x218
#12 0x809df93d at ether_demux+0x14d
#13 0x809dfc1e at ether_nh_input+0x1fe
#14 0x809e8858 at netisr_dispatch_src+0x218
#15 0x809df85f at ether_demux+0x6f
#16 0x809dfc1e at ether_nh_input+0x1fe
#17 0x809e8858 at netisr_dispatch_src+0x218
Uptime: 17d7h20m59s
Dumping 2932 out of 12256 MB: (CTRL-C to abort)
.1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
Reading symbols from /boot/kernel/aio.ko...Reading symbols from
/boot/kernel/aio.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/aio.ko
Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from
/boot/kernel/coretemp.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/coretemp.ko
Reading symbols from /boot/kernel/cc_htcp.ko...Reading symbols from
/boot/kernel/cc_htcp.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/cc_htcp.ko
#0 doadump (textdump=Variable textdump is not available.
) at pcpu.h:234
234 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) list *0x8033d350
0x8033d350 is in pf_addrcpy (/usr/src/sys/contrib/pf/net/pf.c:512).
507 pf_addrcpy(struct pf_addr *dst, struct pf_addr *src, sa_family_t af)
508 {
509 switch (af) {
510 #ifdef INET
511 case AF_INET:
512 dst-addr32[0] = src-addr32[0];
513 break;
514 #endif /* INET */
515 case AF_INET6:
516 dst-addr32[0] = src-addr32[0];
(kgdb) backtrace
#0 doadump (textdump=Variable textdump is not available.
) at pcpu.h:234
#1 0x8091bee6 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:454
#2 0x8091c3e7 in panic (fmt=0x1 Address 0x1 out of bounds)
at /usr/src/sys/kern/kern_shutdown.c:642
#3 0x80d31e70 in trap_fatal (frame=0xc, eva=Variable eva is
not available.
) at /usr/src/sys/amd64/amd64/trap.c:878
#4 0x80d321d1 in trap_pfault (frame=0xff8354538400,
usermode=0) at /usr/src/sys/amd64/amd64/trap.c:794
#5 0x80d327d3 in trap (frame=0xff8354538400) at
/usr/src/sys/amd64/amd64/trap.c:456
#6 0x80d1b9d3 in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:232
#7 0x8033d350 in pf_addrcpy (dst=0xfe010c6416b8,
src=0x10, af=2 '\002') at /usr/src/sys/contrib/pf/net/pf.c:522
A 'src' pointer of 0x10 here would explain the crash (and is consistent
with the fault address).
#8 0x8034872d in pf_test_rule (rm=0xff8354538788,
sm=0xff8354538780, direction=1, kif=0xfe0007d08100,
m=0xfe0030555d00, off=20, h=0xfe0030bad00e,
pd=0xff83545386c0, am=0xff8354538790,
rsm=0xff8354538778, ifq=0x0, inp=0x0) at
/usr/src/sys/contrib/pf/net/pf.c:3900
This is actually in pf_create_state(), and it would seem that 'nk' would
have to be NULL for this to happen. However, 'nsn' would have
to be non-NULL.
I think I see a possible bug that is fixed in 10. Try
Re: amd64/189726: microphone not working on 9.2 and 10.0
The following reply was made to PR amd64/189726; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: Viktor victor...@ukr.net, freebsd-gnats-sub...@freebsd.org, Alexander Motin m...@freebsd.org Cc: Subject: Re: amd64/189726: microphone not working on 9.2 and 10.0 Date: Thu, 15 May 2014 07:12:37 -0400 On 5/12/14, 1:26 PM, Viktor wrote: Number: 189726 Category: amd64 Synopsis: microphone not working on 9.2 and 10.0 Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Mon May 12 17:30:01 UTC 2014 Closed-Date: Last-Modified: Originator: Viktor Release:9.2 Organization: - Environment: FreeBSD dell 9.2-RELEASE-p1 FreeBSD 9.2-RELEASE-p1 #6: Sun Nov 24 11:20:14 EET 2013 vic@dell:/usr/obj/usr/src/sys/m4500 amd64 cat /dev/sndstat FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64) Installed devices: pcm0: NVIDIA GT220 (HDMI/DP 8ch) (play) pcm1: NVIDIA GT220 (HDMI/DP 8ch) (play) pcm2: NVIDIA GT220 (HDMI/DP 8ch) (play) pcm3: NVIDIA GT220 (HDMI/DP 8ch) (play) pcm4: IDT 92HD81B1C (Analog 2.0+HP/2.0) (play/rec) default pcm5: IDT 92HD81B1C (Analog) (play/rec) # mixer Mixer vol is currently set to 88:88 Mixer pcm is currently set to 96:96 Mixer speaker is currently set to 90:90 Mixer line is currently set to 0:0 Mixer mic is currently set to 80:80 Mixer mix is currently set to 59:59 Mixer rec is currently set to 100:100 Mixer ogainis currently set to 100:100 Description: I have no problem with playing sound, I tested it by dd if=file of=/dev/dsp But the microphone is not working, I didn't hear anything doing dd if=/dev/dsp of=/dev/dsp. I have such problem not only on my customized kernel (FreeBSD 9.2), but also on the live CD of FreeBSD 10.0. I have done a test on the live CD FreeBSD 9.0 - everything OK with playing and recording. Everyting ok with dd if=/dev/dsp of=/dev/dsp test. How-To-Repeat: dd if=/dev/dsp of=/dev/dsp on live-CD 9.0 - everything OK. dd if=/dev/dsp of=/dev/dsp on live-CD 10.0 - not working. Fix: Can you get /dev/sndstat output from 9.0? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/189668: Using arcconf on FreeBSD 11 Current Causes Dumps Root User To DB Prompt
The following reply was made to PR amd64/189668; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: Pete Long p...@nrth.org, freebsd-gnats-sub...@freebsd.org Cc: Subject: Re: amd64/189668: Using arcconf on FreeBSD 11 Current Causes Dumps Root User To DB Prompt Date: Thu, 15 May 2014 07:11:21 -0400 On 5/11/14, 10:46 AM, Pete Long wrote: Number: 189668 Category: amd64 Synopsis: Using arcconf on FreeBSD 11 Current Causes Dumps Root User To DB Prompt Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Sun May 11 14:50:00 UTC 2014 Closed-Date: Last-Modified: Originator: Pete Long Release:10.0-STABLE FreeBSD Organization: n/a Environment: FreeBSD frak.nrth.lab 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r265678: Thu May 8 15:37:57 BST 2014 r...@frak.nrth.lab:/usr/obj/usr/src/sys/RAWSEX amd64 Previously running the kernel below with no issues: FreeBSD frak.nrth.lab 10.0-RELEASE-p2 FreeBSD 10.0-RELEASE-p2 #0: Tue Apr 29 17:06:01 UTC 2014 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Description: Hi all, More than likely a case of PEBKAC but here goes. I have an HP Proliant ML110 G5 server using an Adaptec 3405 RAID controller (3 x SATA drives. Cannot afford SAS). I updated my kernel to 11.0-CURRENT using svn and also updated the ports tree in the same manner. Everything I need to run works fine except for one program in ports; namely arcconf. Running '/usr/local/sbin/arcconf GETCONFIG 1' drops my root prompt to a 'DB' prompt with some talk of a KDB backtrace. Apologies if this isn't any help but here is the output generated right after that command (whilst running the 11.0-CURRENT kernel) in dmesg: [Begin dmesg stdout] May 10 23:21:41 frak kernel: KDB: stack backtrace: May 10 23:21:41 frak kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe023334bdb0 May 10 23:21:41 frak kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe023334be60 May 10 23:21:41 frak kernel: witness_checkorder() at witness_checkorder+0xdc2/frame 0xfe023334bef0 May 10 23:21:41 frak kernel: __lockmgr_args() at __lockmgr_args+0x9ca/frame 0xfe023334c020 May 10 23:21:41 frak kernel: ffs_lock() at ffs_lock+0x84/frame 0xfe023334c070 May 10 23:21:41 frak kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfe023334c0a0 May 10 23:21:41 frak kernel: _vn_lock() at _vn_lock+0xaa/frame 0xfe023334c110 May 10 23:21:41 frak kernel: vget() at vget+0x67/frame 0xfe023334c150 May 10 23:21:41 frak kernel: vfs_hash_get() at vfs_hash_get+0xe1/frame 0xfe023334c1a0 May 10 23:21:41 frak kernel: ffs_vgetf() at ffs_vgetf+0x40/frame 0xfe023334c230 May 10 23:21:41 frak kernel: softdep_sync_buf() at softdep_sync_buf+0xafc/frame 0xfe023334c310 May 10 23:21:41 frak kernel: ffs_syncvnode() at ffs_syncvnode+0x286/frame 0xfe023334c390 May 10 23:21:41 frak kernel: ffs_truncate() at ffs_truncate+0x6ae/frame 0xfe023334c570 May 10 23:21:41 frak kernel: ufs_direnter() at ufs_direnter+0x81a/frame 0xfe023334c630 May 10 23:21:41 frak kernel: ufs_makeinode() at ufs_makeinode+0x560/frame 0xfe023334c7e0 May 10 23:21:41 frak kernel: VOP_CREATE_APV() at VOP_CREATE_APV+0xf1/frame 0xfe023334c810 May 10 23:21:41 frak kernel: vn_open_cred() at vn_open_cred+0x2eb/frame 0xfe023334c960 May 10 23:21:41 frak kernel: kern_openat() at kern_openat+0x26f/frame 0xfe023334cae0 May 10 23:21:41 frak kernel: amd64_syscall() at amd64_syscall+0x25a/frame 0xfe023334cbf0 May 10 23:21:41 frak kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe023334cbf0 May 10 23:21:41 frak kernel: --- syscall (5, FreeBSD ELF64, sys_open), rip = 0x800de47ca, rsp = 0x7fffd608, rbp = 0x7fffd6f0 A WITNESS warning shouldn't drop to db. Also, if you reboot from db, usually any messages you get from DDB don't get logged. I suspect this is just an unrelated LOR warning before the actual crash you are seeing. Can you ensure your system is configured for crashdumps and get a dump? It would be good to get the message just before the db prompt (which is likely a panic message) as well as the stack trace of the dump from kgdb. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/189264: [boot] FreeBSD 9.2 and 10.0 does not boot on Tyan Thunder h2000M S3992G3NR-Board
On Saturday, May 03, 2014 10:36:22 pm lini...@freebsd.org wrote: Old Synopsis: FreeBSD 9.2 and 10.0 does not boot on Tyan Thunder h2000M S3992G3NR-Board New Synopsis: [boot] FreeBSD 9.2 and 10.0 does not boot on Tyan Thunder h2000M S3992G3NR-Board Responsible-Changed-From-To: freebsd-bugs-freebsd-amd64 Responsible-Changed-By: linimon Responsible-Changed-When: Sun May 4 02:36:06 UTC 2014 Responsible-Changed-Why: reclassify. Can you get the crash messages from the attempt to boot FreeBSD? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: bash usage of fdescfs [was: Re: amd64/188699: Dev tree]
On Monday, April 21, 2014 3:51:33 pm Konstantin Belousov wrote: On Mon, Apr 21, 2014 at 02:31:12PM -0400, John Baldwin wrote: On Thursday, April 17, 2014 2:50:01 pm Konstantin Belousov wrote: The following reply was made to PR amd64/188699; it has been noted by GNATS. From: Konstantin Belousov kostik...@gmail.com To: John Allman free...@hugme.org Cc: freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/188699: Dev tree Date: Thu, 17 Apr 2014 21:44:52 +0300 On Wed, Apr 16, 2014 at 05:32:45PM +, John Allman wrote: This is how to reproduce it: Fresh install of 10 on AMD 64 install bash `pkg install bash` Switch to bash `bash` push a here document into a loop: `while true ; do echo; done (echo 123)` receive an error: -su: /dev/fd/62: No such file or directory I'm sorry I haven't been able to research this any further. I found how while working on some important matters. As I mentioned the above works fine in all previous versions of FreeBSD up until 10. How-To-Repeat: Fresh install pkg install bash bash while true; do echo foo done (echo 123) -su: /dev/fd/62: No such file or directory So do you have fdescfs mounted on /dev/fd on the machine where the test fails ? It works for me on head, and if unmounted, I get the same failure message as yours. I very much doubt that it has anything to do with a system version. Question I have is why is bash deciding to use /dev/fd/n and require fdescfs? On older releases bash uses named pipes for this instead. The aclocal.m4 contains the test which verifies the presence and usability of /dev/fd/n for n=3 on the _build_ host. The result of the test is used on the installation host afterward. Such kinds of bugs are endemic in our ports, but apparently upstreams are guilty too. Yuck, yuck. Should we fix our default package builders to not mount fdescfs? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/175780: Crash on KVM boot due to xsave instruction issue
On Wednesday, February 26, 2014 5:10:01 pm Sean M. Collins wrote: The following reply was made to PR amd64/175780; it has been noted by GNATS. From: Sean M. Collins s...@coreitpro.com To: bug-follo...@freebsd.org;, kaloqn.ganc...@gmail.com Cc: Subject: Re: amd64/175780: Crash on KVM boot due to xsave instruction issue Date: Wed, 26 Feb 2014 16:37:38 -0500 --P9KQiUGMzYCFwWCN Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I also recently hit this issue when trying to launch a FreeBSD 10-RELEASE guest in an OpenStack environment, with Ubuntu 12.04 LTS hypervisors that use KVM. Did a quick google, and saw this message from the LKML: https://lkml.org/lkml/2014/2/22/58 I don't know that that is relevant. That change effects the size of the save area returned, but it does not fix the fact that the cpuid is returning no features supported at all for xcr0. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/185623: [install] freebsd 10.0-RC5 fresh install does not boot on asus h87m-e
On Friday, February 14, 2014 8:53:30 am Nathan Whitehorn wrote:
On 01/28/14 09:57, John Baldwin wrote:
On Wednesday, January 22, 2014 4:40:01 pm Ryan Stark wrote:
The following reply was made to PR amd64/185623; it has been noted by
GNATS.
From: Ryan Stark rst...@rackspace.com
To: bug-follo...@freebsd.org, nos...@morphium.org
Cc:
Subject: Re: amd64/185623: [install] freebsd 10.0-RC5 fresh install does
not
boot on asus h87m-e
Date: Wed, 22 Jan 2014 15:34:56 -0600
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello,
Seems with a little homework, I was able to boot my new 10.0-RELEASE OS.
=)
After install, but before reboot, run: gpart set -a active ada0
It appears that other asus users of H85 H87 motherboards are
experiencing the same issue.
Hmm, the installer for FreeBSD/{amd64,i386} is supposed to do this
automatically. We used to set this in the PMBR by default for all GPT
setups,
but that isn't really correct for the GPT standard and needs to not be
present
when using EFI. The solution was supposed to be that we would stop setting
it
in the PMBR by default and change the installer to set this bit when doing a
non-EFI GPT install on x86. I think the first part of that (not setting
active by default) happened in 10, but not the second part (fix the
installer
for non-EFI GPT installs on x86). I've cc'd some folks who've worked on
bsdinstall who can hopefully get this fixed.
Interesting, I wasn't aware of this change. So this is an attribute of
the entire geom? It's an easy enough change to make, but I want to be
sure I'm doing the right thing.
Yes, it's a setting applied to the GPT I believe, though I'm not actually sure
if gpart allows setting this flag directly currently. It may be that we need
that added to gpart so that there is a non-hacky way to set this flag in the
PMBR.
--
John Baldwin
___
freebsd-amd64@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/186061: FreeBSD 10 crashes as KVM guest on GNU/Linux on AMD family 10h CPUs
On Thursday, February 13, 2014 09:37:52 AM Simon Matter wrote: On Wednesday, February 12, 2014 4:04:53 pm Simon Matter wrote: On Wednesday, February 12, 2014 2:40:01 am Simon Matter wrote: The following reply was made to PR amd64/186061; it has been noted by GNATS. From: Simon Matter simon.mat...@invoca.ch To: bug-follo...@freebsd.org Cc: simon.mat...@invoca.ch Subject: Re: amd64/186061: FreeBSD 10 crashes as KVM guest on GNU/Linux on AMD family 10h CPUs Date: Wed, 12 Feb 2014 08:30:51 +0100 --=_20140212083051_97180 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit As noted by John Baldwin the change to mca.c is not needed. Attached patch is what I'm using now with success. BTW: setting vm.pmap.pg_ps_enabled=0 in loader.conf does also mitigate the issue but I guess it's not the optimal solution. Talking with Alan Cox, we do think the right fix is to change the test to enable the workaround. However, we'd rather not penalize VM's on other I'm afraid that will not work in all situations, no matter how good the tests are (see below why I think so). So as a last resort, I suggest that it should be possible to enable the AMD Erratum 383 workaround via loader.conf. I think you misunderstand. We would only use flags that are never set on an AMD 10h CPU, so they can never be set in a KVM guest that would ever migrate to an AMD 10h CPU. If those flags are present, we know that we would _not_ need the workaround. If none of those flags are present, we would enable the workaround. Does that make sense? OK, I think I understand now. Unfortunately I don't know enough about CPU flags to know how well this could work. If I understand correctly, KVM can also emulate some CPU features which are not implemented in the real CPU. If that's true then it becomes quite complicated I guess. What about having a sysctl flag so that the workaround can be enabled manually? Wouldn't that make sense for cases where auto detection doesn't work well. I think that is probably a good idea, yes. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/186061: FreeBSD 10 crashes as KVM guest on GNU/Linux on AMD family 10h CPUs
On Wednesday, February 12, 2014 4:04:53 pm Simon Matter wrote: On Wednesday, February 12, 2014 2:40:01 am Simon Matter wrote: The following reply was made to PR amd64/186061; it has been noted by GNATS. From: Simon Matter simon.mat...@invoca.ch To: bug-follo...@freebsd.org Cc: simon.mat...@invoca.ch Subject: Re: amd64/186061: FreeBSD 10 crashes as KVM guest on GNU/Linux on AMD family 10h CPUs Date: Wed, 12 Feb 2014 08:30:51 +0100 --=_20140212083051_97180 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit As noted by John Baldwin the change to mca.c is not needed. Attached patch is what I'm using now with success. BTW: setting vm.pmap.pg_ps_enabled=0 in loader.conf does also mitigate the issue but I guess it's not the optimal solution. Talking with Alan Cox, we do think the right fix is to change the test to enable the workaround. However, we'd rather not penalize VM's on other I'm afraid that will not work in all situations, no matter how good the tests are (see below why I think so). So as a last resort, I suggest that it should be possible to enable the AMD Erratum 383 workaround via loader.conf. I think you misunderstand. We would only use flags that are never set on an AMD 10h CPU, so they can never be set in a KVM guest that would ever migrate to an AMD 10h CPU. If those flags are present, we know that we would _not_ need the workaround. If none of those flags are present, we would enable the workaround. Does that make sense? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/186061: FreeBSD 10 crashes as KVM guest on GNU/Linux on AMD family 10h CPUs
On Friday, February 07, 2014 8:07:07 am Simon Matter wrote: On Thursday, February 06, 2014 6:00:01 am Simon Matter wrote: The following reply was made to PR amd64/186061; it has been noted by GNATS. From: Simon Matter simon.mat...@invoca.ch To: bug-follo...@freebsd.org Cc: simon.mat...@invoca.ch Subject: Re: amd64/186061: FreeBSD 10 crashes as KVM guest on GNU/Linux on AMD family 10h CPUs Date: Thu, 6 Feb 2014 11:46:41 +0100 --=_20140206114641_95473 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, After thinking about it again it seems the proposed solution may not be enough. At least KVM allows to migrate guests from an Intel to an AMD processor. That means in case of running as a vm guest, it's required to always enable AMD Erratum 383 workaround. Otherwise, after migration to an affected AMD Family 10h processor, the guest could triggered AMD Erratum 383. I've tried to implement this and attached patch fixes the problem for me. Would me nice if someone with more experience than me could have a look at it. I suspect you do not need the mca.c change as I doubt any hypervisors are going to pass machine check handling on to guests. Presumably they will handle that in the host OS instead. Hi John, you are right, my test box is also working without the mca.c change. BTW, setting vm.pmap.pg_ps_enabled=0 in loader.conf also helps to make the vm survive but I guess that's not the same and should be avoided? Isn't the suggested patch the better solution? Yes, I think it is, just talking to alc@ about it. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/186061: FreeBSD 10 crashes as KVM guest on GNU/Linux on AMD family 10h CPUs
On Thursday, February 06, 2014 6:00:01 am Simon Matter wrote: The following reply was made to PR amd64/186061; it has been noted by GNATS. From: Simon Matter simon.mat...@invoca.ch To: bug-follo...@freebsd.org Cc: simon.mat...@invoca.ch Subject: Re: amd64/186061: FreeBSD 10 crashes as KVM guest on GNU/Linux on AMD family 10h CPUs Date: Thu, 6 Feb 2014 11:46:41 +0100 --=_20140206114641_95473 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, After thinking about it again it seems the proposed solution may not be enough. At least KVM allows to migrate guests from an Intel to an AMD processor. That means in case of running as a vm guest, it's required to always enable AMD Erratum 383 workaround. Otherwise, after migration to an affected AMD Family 10h processor, the guest could triggered AMD Erratum 383. I've tried to implement this and attached patch fixes the problem for me. Would me nice if someone with more experience than me could have a look at it. I suspect you do not need the mca.c change as I doubt any hypervisors are going to pass machine check handling on to guests. Presumably they will handle that in the host OS instead. Thanks, Simon --=_20140206114641_95473 Content-Type: text/x-diff; name=vm-erratum383.patch Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename=vm-erratum383.patch --- /usr/src/sys/x86/x86/mca.c.orig 2014-01-16 21:35:03.0 +0100 +++ /usr/src/sys/x86/x86/mca.c 2014-02-05 22:15:53.109619475 +0100 @@ -720,8 +720,8 @@ * parity (L1TP) errors is disabled, enable the recommended workaround * for Erratum 383. */ -if (cpu_vendor_id == CPU_VENDOR_AMD -CPUID_TO_FAMILY(cpu_id) == 0x10 amd10h_L1TP) +if (vm_guest != VM_GUEST_NO || (cpu_vendor_id == CPU_VENDOR_AMD +CPUID_TO_FAMILY(cpu_id) == 0x10 amd10h_L1TP)) workaround_erratum383 = 1; mca_banks = mcg_cap MCG_CAP_COUNT; --- /usr/src/sys/i386/i386/pmap.c.orig 2014-01-16 21:33:36.0 +0100 +++ /usr/src/sys/i386/i386/pmap.c2014-02-05 22:25:28.395821316 +0100 @@ -752,12 +752,12 @@ pv_entry_high_water = 9 * (pv_entry_max / 10); /* - * If the kernel is running in a virtual machine on an AMD Family 10h - * processor, then it must assume that MCA is enabled by the virtual - * machine monitor. + * If the kernel is running in a virtual machine on any processor + * family, then it must assume that MCA is enabled by the virtual + * machine monitor and the vm may migrate to an AMD Family 10h + * processor. */ -if (vm_guest == VM_GUEST_VM cpu_vendor_id == CPU_VENDOR_AMD -CPUID_TO_FAMILY(cpu_id) == 0x10) +if (vm_guest != VM_GUEST_NO) workaround_erratum383 = 1; /* --- /usr/src/sys/amd64/amd64/pmap.c.orig 2014-01-16 21:33:04.0 +0100 +++ /usr/src/sys/amd64/amd64/pmap.c 2014-02-05 22:28:25.814349113 +0100 @@ -1005,12 +1005,12 @@ } /* - * If the kernel is running in a virtual machine on an AMD Family 10h - * processor, then it must assume that MCA is enabled by the virtual - * machine monitor. + * If the kernel is running in a virtual machine on any processor + * family, then it must assume that MCA is enabled by the virtual + * machine monitor and the vm may migrate to an AMD Family 10h + * processor. */ -if (vm_guest == VM_GUEST_VM cpu_vendor_id == CPU_VENDOR_AMD -CPUID_TO_FAMILY(cpu_id) == 0x10) +if (vm_guest != VM_GUEST_NO) workaround_erratum383 = 1; /* --=_20140206114641_95473-- ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/186515: Doesn't boot with GPT when # of entries over than 128.
On Thursday, February 06, 2014 12:43:48 pm yeong@freebsd.org, Jo wrote: Number: 186515 Category: amd64 Synopsis: Doesn't boot with GPT when # of entries over than 128. Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Thu Feb 06 17:50:00 UTC 2014 Closed-Date: Last-Modified: Originator: Yeong Hun, Jo Release:FreeBSD 10.0-RELEASE Organization: - Environment: FreeBSD localhost 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 1 22:34:59 UTC 2014 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 Description: I tried to making USB memory stick using GPT partition table scheme. I usually use 152 entries to aligning 4KB boundary for data disk(start location) and use 156 entries to aligning 4KB boundary for system disk(end location, misalignment of start location is used for boot code and make 4KB aligned root partition). I don't like that some free sectors on disk :-) But, it failed to boot when partition entry count is adjusted to more than 128. * WORKS : 128 entries GPT(1st usable sector = 34) with freebsd-boot partition at sector 34, 40. * DOESN'T WORK : 152 entries GPT(1st usable sector = 40) with freebsd-boot partition at sector 40, 156 entries GPT(1st usable sector = 41) with freebsd- boot partition at sector 41. Yes, There's no problem with default size GPT partition table. 128 entires - minimum entry count by spec. - seems to be sufficient at most cases. But, that can be arbitrary size and should be supported even that cases. I think there's some issue on gpart or early-stage boot loader(/boot/pmbr). How-To-Repeat: * For example, USB disk is da0 here. # gpart create -s gpt -n 152 da0 # gpart add -t freebsd-boot -b 40 -s 32 -i 1 da0 # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 da0 and try to boot USB. It should be show clockwise loading screen even no freebsd-ufs partition on USB, but it doesn't show anything and reboot immediately. It(doesn't say anything and reboot) occurs with /boot populated freebsd-ufs partition, too. Using more entries to pad out the table isn't the normal way to handle 4k alignment. You can just leave a gap before the start of freebsd-boot. Having the sectors free vs having them contain zero'd GPT entries doesn't really make a difference. One question is when does the boot break? Does it make it into the loader and break trying to boot the kernel? Does it make it into gptboot and break trying to load the loader? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/186291: Compilation fail when device pst in kernel config on amd64.
On Friday, January 31, 2014 2:00:27 am Ivan Chetyrkin wrote: Number: 186291 Category: amd64 Synopsis: Compilation fail when device pst in kernel config on amd64. Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Fri Jan 31 07:10:00 UTC 2014 Closed-Date: Last-Modified: Originator: Ivan Chetyrkin Release:10.0-STABLE Organization: Environment: FreeBSD v64.devel.local 10.0-STABLE FreeBSD 10.0-STABLE #0: Thu Jan 30 21:31:03 UTC 2014 root@v64.devel.local:/usr/obj/usr/src/sys/VBOX64 amd64 Description: When trying to compile my own kernel with device pst in configuration file, process fail with message: cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls - Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith - Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing- include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno- error-empty-body -Wno-error-parentheses-equality -nostdinc -I. - I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt - D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame- pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno- red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables - ffreestanding -fstack-protector -Werror /usr/src/sys/dev/pst/pst-iop.c /usr/src/sys/dev/pst/pst-iop.c:197:3: error: cast to 'void (*)(struct iop_softc *, u_int32_t, struct i2o_single_reply *)' from smaller integer type 'u_int32_t' (aka 'unsigned int') [-Werror,-Wint-to-pointer-cast] ((void (*)(struct iop_softc *, u_int32_t, struct i2o_single_reply *)) ^ /usr/src/sys/dev/pst/pst-iop.c:419:9: error: cast to 'struct iop_request *' from smaller integer type 'u_int32_t' (aka 'unsigned int') [-Werror,-Wint-to- pointer-cast] (struct iop_request *)reply-transaction_context; ^ 2 errors generated. As we see from /usr/src/sys/dev/pst/pst-iop.h, initiator_context and transaction_context fields of driver message struct are declared as u_int32_t, which doesn't match pointer size on 64-bit processor. How-To-Repeat: On amd64 machine include device pst in your config file and try compile kernel. Fix: The controller is very old hardware and one of fix may be exclude it from available devices on amd64 platform. Yes, this driver is not supported on amd64. Do you need it to work? You would need to implement a cookie hash table of some sort to map transaction context IDs to request pointers. If you do not need it, we should probably disable it on amd64 as no one else has asked about it. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/186289: Update to 9.2 not possible.
On Friday, January 31, 2014 1:20:29 am Hubert wrote: Number: 186289 Category: amd64 Synopsis: Update to 9.2 not possible. Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: update Submitter-Id: current-users Arrival-Date: Fri Jan 31 06:30:01 UTC 2014 Closed-Date: Last-Modified: Originator: Hubert Release:9.1 Organization: Environment: AcernAspire 5542G AMD Turion X2 M500 ATI Mobility R adion HD4570 Can you provide more details? What does not work? Are there any error messages? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/186291: Compilation fail when device pst in kernel config on amd64.
The following reply was made to PR amd64/186291; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: freebsd-amd64@freebsd.org Cc: Ivan Chetyrkin fr...@inbox.ru, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/186291: Compilation fail when device pst in kernel config on amd64. Date: Thu, 6 Feb 2014 13:22:52 -0500 On Friday, January 31, 2014 2:00:27 am Ivan Chetyrkin wrote: Number: 186291 Category: amd64 Synopsis: Compilation fail when device pst in kernel config on amd64. Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Fri Jan 31 07:10:00 UTC 2014 Closed-Date: Last-Modified: Originator: Ivan Chetyrkin Release:10.0-STABLE Organization: Environment: FreeBSD v64.devel.local 10.0-STABLE FreeBSD 10.0-STABLE #0: Thu Jan 30 21:31:03 UTC 2014 root@v64.devel.local:/usr/obj/usr/src/sys/VBOX64 amd64 Description: When trying to compile my own kernel with device pst in configuration file, process fail with message: cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls - Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith - Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing- include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno- error-empty-body -Wno-error-parentheses-equality -nostdinc -I. - I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt - D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame- pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno- red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables - ffreestanding -fstack-protector -Werror /usr/src/sys/dev/pst/pst-iop.c /usr/src/sys/dev/pst/pst-iop.c:197:3: error: cast to 'void (*)(struct iop_softc *, u_int32_t, struct i2o_single_reply *)' from smaller integer type 'u_int32_t' (aka 'unsigned int') [-Werror,-Wint-to-pointer-cast] ((void (*)(struct iop_softc *, u_int32_t, struct i2o_single_reply *)) ^ /usr/src/sys/dev/pst/pst-iop.c:419:9: error: cast to 'struct iop_request *' from smaller integer type 'u_int32_t' (aka 'unsigned int') [-Werror,-Wint-to- pointer-cast] (struct iop_request *)reply-transaction_context; ^ 2 errors generated. As we see from /usr/src/sys/dev/pst/pst-iop.h, initiator_context and transaction_context fields of driver message struct are declared as u_int32_t, which doesn't match pointer size on 64-bit processor. How-To-Repeat: On amd64 machine include device pst in your config file and try compile kernel. Fix: The controller is very old hardware and one of fix may be exclude it from available devices on amd64 platform. Yes, this driver is not supported on amd64. Do you need it to work? You would need to implement a cookie hash table of some sort to map transaction context IDs to request pointers. If you do not need it, we should probably disable it on amd64 as no one else has asked about it. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/186289: Update to 9.2 not possible.
The following reply was made to PR amd64/186289; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: freebsd-amd64@freebsd.org Cc: Hubert hp...@arcor.de, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/186289: Update to 9.2 not possible. Date: Thu, 6 Feb 2014 13:20:20 -0500 On Friday, January 31, 2014 1:20:29 am Hubert wrote: Number: 186289 Category: amd64 Synopsis: Update to 9.2 not possible. Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: update Submitter-Id: current-users Arrival-Date: Fri Jan 31 06:30:01 UTC 2014 Closed-Date: Last-Modified: Originator: Hubert Release:9.1 Organization: Environment: AcernAspire 5542G AMD Turion X2 M500 ATI Mobility R adion HD4570 Can you provide more details? What does not work? Are there any error messages? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/185623: [install] freebsd 10.0-RC5 fresh install does not boot on asus h87m-e
On Wednesday, January 22, 2014 4:40:01 pm Ryan Stark wrote:
The following reply was made to PR amd64/185623; it has been noted by GNATS.
From: Ryan Stark rst...@rackspace.com
To: bug-follo...@freebsd.org, nos...@morphium.org
Cc:
Subject: Re: amd64/185623: [install] freebsd 10.0-RC5 fresh install does not
boot on asus h87m-e
Date: Wed, 22 Jan 2014 15:34:56 -0600
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello,
Seems with a little homework, I was able to boot my new 10.0-RELEASE OS. =)
After install, but before reboot, run: gpart set -a active ada0
It appears that other asus users of H85 H87 motherboards are
experiencing the same issue.
Hmm, the installer for FreeBSD/{amd64,i386} is supposed to do this
automatically. We used to set this in the PMBR by default for all GPT setups,
but that isn't really correct for the GPT standard and needs to not be present
when using EFI. The solution was supposed to be that we would stop setting it
in the PMBR by default and change the installer to set this bit when doing a
non-EFI GPT install on x86. I think the first part of that (not setting
active by default) happened in 10, but not the second part (fix the installer
for non-EFI GPT installs on x86). I've cc'd some folks who've worked on
bsdinstall who can hopefully get this fixed.
--
John Baldwin
___
freebsd-amd64@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/184304: Broadcom NetXtreme BCM57786 Gigabit Ethernet NIC not working
On Tuesday, November 26, 2013 3:18:17 am Sastry Tumuluri wrote:
Number: 184304
Category: amd64
Synopsis: Broadcom NetXtreme BCM57786 Gigabit Ethernet NIC not
working
Confidential: no
Severity: non-critical
Priority: low
Responsible:freebsd-amd64
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Tue Nov 26 08:20:00 UTC 2013
Closed-Date:
Last-Modified:
Originator: Sastry Tumuluri
Release:10.0BETA3
Organization:
Government of Haryana
Environment:
FreeBSD 10.0-BETA3 #0 r257580: Sun Nov 3 19:43:01 UTC 2013
r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
Description:
Laptop: Acer Aspire E1-572-54204G50Mnkk
Ethernet NIC not recognized on boot.
pciconf shows:
none2@pci0:1:0:0: class=0x02 card=0x07751025 chip=0x16b314e4 rev=0x01
hdr=0x00
vendor = 'Broadcom Corportation'
device = 'NetXtreme BCM57786 Gigabit Ethernet PCIe'
class= network
subclass = ethernet
Please try this but report back with the dmesg:
Index: head/sys/dev/bge/if_bge.c
===
--- head/sys/dev/bge/if_bge.c (revision 258648)
+++ head/sys/dev/bge/if_bge.c (working copy)
@@ -221,11 +221,16 @@
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57760 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57761 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57762 },
+ { BCOM_VENDORID,BCOM_DEVICEID_BCM57764 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57765 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57766 },
+ { BCOM_VENDORID,BCOM_DEVICEID_BCM57767 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57780 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57781 },
+ { BCOM_VENDORID,BCOM_DEVICEID_BCM57782 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57785 },
+ { BCOM_VENDORID,BCOM_DEVICEID_BCM57786 },
+ { BCOM_VENDORID,BCOM_DEVICEID_BCM57787 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57788 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57790 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57791 },
@@ -2694,6 +2699,9 @@
case BCOM_DEVICEID_BCM5725:
case BCOM_DEVICEID_BCM5727:
case BCOM_DEVICEID_BCM5762:
+ case BCOM_DEVICEID_BCM57764:
+ case BCOM_DEVICEID_BCM57767:
+ case BCOM_DEVICEID_BCM57787:
id = pci_read_config(dev,
BGE_PCI_GEN2_PRODID_ASICREV, 4);
break;
@@ -2702,7 +2710,9 @@
case BCOM_DEVICEID_BCM57765:
case BCOM_DEVICEID_BCM57766:
case BCOM_DEVICEID_BCM57781:
+ case BCOM_DEVICEID_BCM57782:
case BCOM_DEVICEID_BCM57785:
+ case BCOM_DEVICEID_BCM57786:
case BCOM_DEVICEID_BCM57791:
case BCOM_DEVICEID_BCM57795:
id = pci_read_config(dev,
Index: head/sys/dev/bge/if_bgereg.h
===
--- head/sys/dev/bge/if_bgereg.h(revision 258648)
+++ head/sys/dev/bge/if_bgereg.h(working copy)
@@ -2503,11 +2503,16 @@
#defineBCOM_DEVICEID_BCM57760 0x1690
#defineBCOM_DEVICEID_BCM57761 0x16B0
#defineBCOM_DEVICEID_BCM57762 0x1682
+#defineBCOM_DEVICEID_BCM57764 0x1642
#defineBCOM_DEVICEID_BCM57765 0x16B4
#defineBCOM_DEVICEID_BCM57766 0x1686
+#defineBCOM_DEVICEID_BCM57767 0x1683
#defineBCOM_DEVICEID_BCM57780 0x1692
#defineBCOM_DEVICEID_BCM57781 0x16B1
+#defineBCOM_DEVICEID_BCM57782 0x16B7
#defineBCOM_DEVICEID_BCM57785 0x16B5
+#defineBCOM_DEVICEID_BCM57786 0x16B3
+#defineBCOM_DEVICEID_BCM57787 0x1641
#defineBCOM_DEVICEID_BCM57788 0x1691
#defineBCOM_DEVICEID_BCM57790 0x1694
#defineBCOM_DEVICEID_BCM57791 0x16B2
--
John Baldwin
___
freebsd-amd64@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/184304: Broadcom NetXtreme BCM57786 Gigabit Ethernet NIC not working
The following reply was made to PR amd64/184304; it has been noted by GNATS.
From: John Baldwin j...@freebsd.org
To: freebsd-amd64@freebsd.org
Cc: Sastry Tumuluri s...@tumuluri.name,
freebsd-gnats-sub...@freebsd.org,
yong...@freebsd.org
Subject: Re: amd64/184304: Broadcom NetXtreme BCM57786 Gigabit Ethernet NIC not
working
Date: Tue, 26 Nov 2013 14:01:54 -0500
On Tuesday, November 26, 2013 3:18:17 am Sastry Tumuluri wrote:
Number: 184304
Category: amd64
Synopsis: Broadcom NetXtreme BCM57786 Gigabit Ethernet NIC not
working
Confidential: no
Severity: non-critical
Priority: low
Responsible:freebsd-amd64
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Tue Nov 26 08:20:00 UTC 2013
Closed-Date:
Last-Modified:
Originator: Sastry Tumuluri
Release:10.0BETA3
Organization:
Government of Haryana
Environment:
FreeBSD 10.0-BETA3 #0 r257580: Sun Nov 3 19:43:01 UTC 2013
r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
Description:
Laptop: Acer Aspire E1-572-54204G50Mnkk
Ethernet NIC not recognized on boot.
pciconf shows:
none2@pci0:1:0:0: class=0x02 card=0x07751025 chip=0x16b314e4 rev=0x01
hdr=0x00
vendor = 'Broadcom Corportation'
device = 'NetXtreme BCM57786 Gigabit Ethernet PCIe'
class= network
subclass = ethernet
Please try this but report back with the dmesg:
Index: head/sys/dev/bge/if_bge.c
===
--- head/sys/dev/bge/if_bge.c (revision 258648)
+++ head/sys/dev/bge/if_bge.c (working copy)
@@ -221,11 +221,16 @@
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57760 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57761 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57762 },
+ { BCOM_VENDORID,BCOM_DEVICEID_BCM57764 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57765 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57766 },
+ { BCOM_VENDORID,BCOM_DEVICEID_BCM57767 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57780 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57781 },
+ { BCOM_VENDORID,BCOM_DEVICEID_BCM57782 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57785 },
+ { BCOM_VENDORID,BCOM_DEVICEID_BCM57786 },
+ { BCOM_VENDORID,BCOM_DEVICEID_BCM57787 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57788 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57790 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57791 },
@@ -2694,6 +2699,9 @@
case BCOM_DEVICEID_BCM5725:
case BCOM_DEVICEID_BCM5727:
case BCOM_DEVICEID_BCM5762:
+ case BCOM_DEVICEID_BCM57764:
+ case BCOM_DEVICEID_BCM57767:
+ case BCOM_DEVICEID_BCM57787:
id = pci_read_config(dev,
BGE_PCI_GEN2_PRODID_ASICREV, 4);
break;
@@ -2702,7 +2710,9 @@
case BCOM_DEVICEID_BCM57765:
case BCOM_DEVICEID_BCM57766:
case BCOM_DEVICEID_BCM57781:
+ case BCOM_DEVICEID_BCM57782:
case BCOM_DEVICEID_BCM57785:
+ case BCOM_DEVICEID_BCM57786:
case BCOM_DEVICEID_BCM57791:
case BCOM_DEVICEID_BCM57795:
id = pci_read_config(dev,
Index: head/sys/dev/bge/if_bgereg.h
===
--- head/sys/dev/bge/if_bgereg.h (revision 258648)
+++ head/sys/dev/bge/if_bgereg.h (working copy)
@@ -2503,11 +2503,16 @@
#define BCOM_DEVICEID_BCM57760 0x1690
#define BCOM_DEVICEID_BCM57761 0x16B0
#define BCOM_DEVICEID_BCM57762 0x1682
+#define BCOM_DEVICEID_BCM57764 0x1642
#define BCOM_DEVICEID_BCM57765 0x16B4
#define BCOM_DEVICEID_BCM57766 0x1686
+#define BCOM_DEVICEID_BCM57767 0x1683
#define BCOM_DEVICEID_BCM57780 0x1692
#define BCOM_DEVICEID_BCM57781 0x16B1
+#define BCOM_DEVICEID_BCM57782 0x16B7
#define BCOM_DEVICEID_BCM57785 0x16B5
+#define BCOM_DEVICEID_BCM57786 0x16B3
+#define BCOM_DEVICEID_BCM57787 0x1641
#define BCOM_DEVICEID_BCM57788 0x1691
#define BCOM_DEVICEID_BCM57790 0x1694
#define BCOM_DEVICEID_BCM57791 0x16B2
--
John Baldwin
___
freebsd-amd64@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/183620: RTL8111/8168B PCIE NIC not detected on any FreeBSD Version
On Sunday, November 03, 2013 9:46:18 am Danny Winn wrote: Number: 183620 Category: amd64 Synopsis: RTL8111/8168B PCIE NIC not detected on any FreeBSD Version Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Sun Nov 03 14:50:00 UTC 2013 Closed-Date: Last-Modified: Originator: Danny Winn Release:8.4, 9.1, 9.2, 10.0-BETA2 (same bug in all releases) Organization: Environment: Every version/kernel/environment mentioned above Description: Hello, we are trying to install FreeBSD on a computer that uses the NIC mentioned above. The NIC is running under linux without problems, which we've tested for several days transferring several GB of data. The NIC is neither detected by the FreeBSD installer when attempting to setup the network, nor after the system installation when booting from HD. We've tested FreeBSD 8.x, 9.x and 10.x; same issues with this NIC. We cannot use a different NIC (this one is onboard. The micro ATX mainboard has no room left for any other device) pciconf -l -v: none2@pci0:3:0:0:class=0x02 card=0x81681849 chip=0x816810ec rev=0x0c hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet dmesg: re0: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet port 0xd000-0xd0ff mem 0xf3204000-0xf3204fff,0xf320-0xf3203fff irq 19 at device 0.0 on pci3 re0: Using 1 MSI-X message re0: Chip rev. 0x4c00 re0: MAC rev. 0x re0: Unknown H/W revision: 0x4c00 device_attach: re0 attach returned 6 It looks like Pyun just merged support for this device into 9.x and 10.x today, e.g.: Log: MFC r257305: Add preliminary support for RTL8168G, RTL8168GU and RTL8411B. RTL8168GU has two variants(GMII and MII) but it uses the same chip revision id. Driver checks PCI device id of controller and sets internal capability flag(i.e. jumbo frame and link speed down in WOL). Modified: stable/9/sys/dev/re/if_re.c stable/9/sys/pci/if_rlreg.h In particular, it adds support for the hwrev you pasted as an 8168G part: +#defineRL_HWREV_8168G 0x4C00 -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/183620: RTL8111/8168B PCIE NIC not detected on any FreeBSD Version
The following reply was made to PR amd64/183620; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: freebsd-amd64@freebsd.org Cc: Danny Winn danny.gabriel.w...@gmail.com, freebsd-gnats-sub...@freebsd.org, yong...@freebsd.org Subject: Re: amd64/183620: RTL8111/8168B PCIE NIC not detected on any FreeBSD Version Date: Mon, 4 Nov 2013 15:06:52 -0500 On Sunday, November 03, 2013 9:46:18 am Danny Winn wrote: Number: 183620 Category: amd64 Synopsis: RTL8111/8168B PCIE NIC not detected on any FreeBSD Version Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Sun Nov 03 14:50:00 UTC 2013 Closed-Date: Last-Modified: Originator: Danny Winn Release:8.4, 9.1, 9.2, 10.0-BETA2 (same bug in all releases) Organization: Environment: Every version/kernel/environment mentioned above Description: Hello, we are trying to install FreeBSD on a computer that uses the NIC mentioned above. The NIC is running under linux without problems, which we've tested for several days transferring several GB of data. The NIC is neither detected by the FreeBSD installer when attempting to setup the network, nor after the system installation when booting from HD. We've tested FreeBSD 8.x, 9.x and 10.x; same issues with this NIC. We cannot use a different NIC (this one is onboard. The micro ATX mainboard has no room left for any other device) pciconf -l -v: none2@pci0:3:0:0:class=0x02 card=0x81681849 chip=0x816810ec rev=0x0c hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet dmesg: re0: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet port 0xd000-0xd0ff mem 0xf3204000-0xf3204fff,0xf320-0xf3203fff irq 19 at device 0.0 on pci3 re0: Using 1 MSI-X message re0: Chip rev. 0x4c00 re0: MAC rev. 0x re0: Unknown H/W revision: 0x4c00 device_attach: re0 attach returned 6 It looks like Pyun just merged support for this device into 9.x and 10.x today, e.g.: Log: MFC r257305: Add preliminary support for RTL8168G, RTL8168GU and RTL8411B. RTL8168GU has two variants(GMII and MII) but it uses the same chip revision id. Driver checks PCI device id of controller and sets internal capability flag(i.e. jumbo frame and link speed down in WOL). Modified: stable/9/sys/dev/re/if_re.c stable/9/sys/pci/if_rlreg.h In particular, it adds support for the hwrev you pasted as an 8168G part: +#defineRL_HWREV_8168G 0x4C00 -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/183397: Kernel panic at first incoming ssh
On Thursday, October 31, 2013 7:50:01 pm Torbjorn Granlund wrote: The following reply was made to PR amd64/183397; it has been noted by GNATS. From: Torbjorn Granlund t...@gmplib.org To: John Baldwin j...@freebsd.org Cc: freebsd-amd64@freebsd.org, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/183397: Kernel panic at first incoming ssh Date: Fri, 01 Nov 2013 00:42:19 +0100 Those attachments didn't come out too pretty at the web PR interface. I put the screen dumps in png format here: http://gmplib.org/~tege/fbsd32-oh-no-ssh.png http://gmplib.org/~tege/fbsd64-oh-no-ssh.png Can you fire up gdb against your 64-bit kernel file (e.g. gdb /boot/kernel/kernel) and do 'l *xn_intr+0x7d'? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/183397: Kernel panic at first incoming ssh
On Friday, November 01, 2013 12:48:54 pm Torbjorn Granlund wrote:
John Baldwin j...@freebsd.org writes:
Can you fire up gdb against your 64-bit kernel file (e.g. gdb
/boot/kernel/kernel) and do 'l *xn_intr+0x7d'?
I'm afraid my ignorance of how to debug the kernel will show itself
here.
I did this:
1. booted the system.
2. logged in as root on the (vnc) console.
3. issued the command gdb /boot/kernel/kernel
4. Issued the above command and got this printout:
(gdb) l *xn_intr+0x7d
0x8079fb7d is in xn_intr (atomic.h:161).
156 atomic.h: No such file ot directory.
in atomic.h
(gdb)
Hummm, I assume you can't get a crashdump when this happens? atomic.h means
it is likely acquiring a lock:
static void
xn_intr(void *xsc)
{
struct netfront_info *np = xsc;
struct ifnet *ifp = np-xn_ifp;
#if 0
if (!(np-rx.rsp_cons != np-rx.sring-rsp_prod
likely(netfront_carrier_ok(np))
ifp-if_drv_flags IFF_DRV_RUNNING))
return;
#endif
if (RING_HAS_UNCONSUMED_RESPONSES(np-tx)) {
XN_TX_LOCK(np);
xn_txeof(np);
XN_TX_UNLOCK(np);
}
XN_RX_LOCK(np);
xn_rxeof(np);
XN_RX_UNLOCK(np);
Either the XN_TX_LOCK() or XN_RX_LOCK(). It's hard to narrow down where the
corruption lies without a dump.
--
John Baldwin
___
freebsd-amd64@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/182740: BTX halted on Jetway NF81 motherboard when RAID is enabled
On Wednesday, October 09, 2013 5:21:05 am Julian Pidancet wrote: On 7 October 2013 16:47, John Baldwin j...@freebsd.org wrote: Ok, can you take this patch and use it to build an updated pxeboot and test if it fixes disk access with AHCI enabled? That seems to have fixed the issue, thanks. Great, thanks! -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/182740: BTX halted on Jetway NF81 motherboard when RAID is enabled
The following reply was made to PR amd64/182740; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: Julian Pidancet julian.pidan...@gmail.com Cc: freebsd-amd64@freebsd.org, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/182740: BTX halted on Jetway NF81 motherboard when RAID is enabled Date: Thu, 10 Oct 2013 11:20:40 -0400 On Wednesday, October 09, 2013 5:21:05 am Julian Pidancet wrote: On 7 October 2013 16:47, John Baldwin j...@freebsd.org wrote: Ok, can you take this patch and use it to build an updated pxeboot and test if it fixes disk access with AHCI enabled? That seems to have fixed the issue, thanks. Great, thanks! -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/182686: bios lost HDD after installing freebsd-9.x
On Saturday, October 05, 2013 10:18:42 am XX wrote: Number: 182686 Category: amd64 Synopsis: bios lost HDD after installing freebsd-9.x Confidential: no Severity: serious Priority: medium Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Sat Oct 05 14:20:00 UTC 2013 Closed-Date: Last-Modified: Originator: áÎÄÒÅÊ Release:9.2 Organization: Environment: Description: I have installed freebsd-9.1 on my AMD 64 machine it worked well. But I have decided to go on 9.2 version and. I booted from usb, create slice and bsd- partitions on IDE hard drive using gpart and newfs. then i used bsdinstall to install the system. after installing i make shutdown -p now. When i turned my computer on, BIOS did not detect any hard drive. Then i installed system on SATA hard drive and have got the same result. When i connect this SATA drive to windows machine via USB - disk is OK. After deleting FreeBSD slice and connecting the disk back to AMD64 its BIOS has detected the drive. Did you use GPT? If so, try using MBR instead for partitioning your disk. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/182568: FreeBSD 10 Alpha 4 fails installation under Hyper-V
On Wednesday, October 02, 2013 6:45:24 am Chavdar Ivanov wrote: Number: 182568 Category: amd64 Synopsis: FreeBSD 10 Alpha 4 fails installation under Hyper-V Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Wed Oct 02 10:50:00 UTC 2013 Closed-Date: Last-Modified: Originator: Chavdar Ivanov Release:FreeBSD 10 Alpha 4 Organization: Delcam Plc Environment: n/a Description: Tried installing FreeBSD-10.0-ALPHA4-amd64-disc1.iso on Hyper-V 2008 R2, Hyper-V 2012 and Hyper-V 2012 R2 (preview) with identical results. The kernel appears not to recognize the CD drive, the message about it does not appear. The last message is as follows: I believe the Hyper-V guys are working on a fix for this. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/182568: FreeBSD 10 Alpha 4 fails installation under Hyper-V
The following reply was made to PR amd64/182568; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: freebsd-amd64@freebsd.org Cc: Chavdar Ivanov c...@delcam.com, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/182568: FreeBSD 10 Alpha 4 fails installation under Hyper-V Date: Mon, 7 Oct 2013 10:28:39 -0400 On Wednesday, October 02, 2013 6:45:24 am Chavdar Ivanov wrote: Number: 182568 Category: amd64 Synopsis: FreeBSD 10 Alpha 4 fails installation under Hyper-V Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Wed Oct 02 10:50:00 UTC 2013 Closed-Date: Last-Modified: Originator: Chavdar Ivanov Release:FreeBSD 10 Alpha 4 Organization: Delcam Plc Environment: n/a Description: Tried installing FreeBSD-10.0-ALPHA4-amd64-disc1.iso on Hyper-V 2008 R2, Hyper-V 2012 and Hyper-V 2012 R2 (preview) with identical results. The kernel appears not to recognize the CD drive, the message about it does not appear. The last message is as follows: I believe the Hyper-V guys are working on a fix for this. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/182686: bios lost HDD after installing freebsd-9.x
The following reply was made to PR amd64/182686; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: freebsd-amd64@freebsd.org Cc: XX reku...@gmail.com, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/182686: bios lost HDD after installing freebsd-9.x Date: Mon, 7 Oct 2013 11:41:27 -0400 On Saturday, October 05, 2013 10:18:42 am XX wrote: =20 Number: 182686 Category: amd64 Synopsis: bios lost HDD after installing freebsd-9.x Confidential: no Severity: serious Priority: medium Responsible:freebsd-amd64 State: open Quarter: =20 Keywords: =20 Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Sat Oct 05 14:20:00 UTC 2013 Closed-Date: Last-Modified: Originator: =E1=CE=C4=D2=C5=CA Release:9.2 Organization: Environment: Description: I have installed freebsd-9.1 on my AMD 64 machine it worked well. But I h= ave=20 decided to go on 9.2 version and. I booted from usb, create slice and bsd- partitions on IDE hard drive using gpart and newfs. then i used bsdinstall = to=20 install the system. after installing i make shutdown -p now. When i turne= d=20 my computer on, BIOS did not detect any hard drive. Then i installed system on SATA hard drive and have got the same result.= =20 When i connect this SATA drive to windows machine via USB - disk is OK. Aft= er=20 deleting FreeBSD slice and connecting the disk back to AMD64 its BIOS has=20 detected the drive. Did you use GPT? If so, try using MBR instead for partitioning your disk. =2D-=20 John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/182740: BTX halted on Jetway NF81 motherboard when RAID is enabled
The following reply was made to PR amd64/182740; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: freebsd-amd64@freebsd.org Cc: Julian Pidancet julian.pidan...@gmail.com, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/182740: BTX halted on Jetway NF81 motherboard when RAID is enabled Date: Mon, 7 Oct 2013 11:47:32 -0400 On Sunday, October 06, 2013 7:28:31 am Julian Pidancet wrote: Number: 182740 Category: amd64 Synopsis: BTX halted on Jetway NF81 motherboard when RAID is enabled Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Sun Oct 06 11:30:00 UTC 2013 Closed-Date: Last-Modified: Originator: Julian Pidancet Release:8.2 Organization: Environment: Description: Just got this brand new motherboard with an AMD APU and an AMD chipset. Whenever I try to boot FreeBSD and AHCI or RAID is enabled in the BIOS, I am getting this message: BTX loader 1.00 BTX version is 1.02 int=000a err= efl=6402 eip=93e0 eax=534d4150 ebx=0001 ecx=0014 edx=534d4150 esi= edi=0004 ebp= esp=004e cs=0008 ds=0033 es=0033fs=0033 gs=0033 ss=0010 cs:eip=cf 83 f8 01 75 1a 16 87-86 1f 1e 0f a1 0f a0 0f a9 b8 00 a0 00 00 03 44-24 0c 8d 60 04 58 ff d0 ss:esp=00 f0 39 e7 00 f0 e3 21-80 ce 2e e8 00 f0 d2 ef 00 f0 00 e0 00 f0 f2 e6-00 f0 6e fe 00 f0 53 ff BTX halted It looks like to me the BTX is taking an Invalid TSS exception while executing an iret instruction. How-To-Repeat: I tried: - Booting from the install cdrom - Booting from an USB install disk - Booting from boot/pxeboot in PXE mode All exhibit the same issue. Fix: Selecting Legacy IDE mode in the BIOS configuration instead of AHCI/RAID. Ok, can you take this patch and use it to build an updated pxeboot and test if it fixes disk access with AHCI enabled? Index: boot/i386/btx/btx/btx.S === --- boot/i386/btx/btx/btx.S(revision 247010) +++ boot/i386/btx/btx/btx.S(working copy) @@ -41,6 +41,8 @@ .set PSL_RESERVED_DEFAULT,0x0002 .set PSL_T,0x0100 # Trap flag .set PSL_I,0x0200 # Interrupt enable flag + .set PSL_D,0x0400 # String instruction direction + .set PSL_NT,0x4000 # Nested task flag .set PSL_VM,0x0002 # Virtual 8086 mode flag .set PSL_AC,0x0004 # Alignment check flag /* @@ -611,8 +613,8 @@ pushl %ds # regs pushl %es pushfl # Save %eflags - cli # Disable interrupts - std # String ops dec + pushl $PSL_RESERVED_DEFAULT|PSL_D # Use clean %eflags with + popfl # string ops dec xorw %ax,%ax# Reset seg movw %ax,%ds# regs movw %ax,%es# (%ss is already 0) @@ -675,6 +677,7 @@ testl $V86F_FLAGS,%edx # User wants flags? jz rret_tramp.3 # No movl MEM_ESPR-0x3c,%eax # Read real mode flags + andl $~(PSL_T|PSL_NT),%eax # Clear unsafe flags movw %ax,-0x08(%esi)# Update user flags (low 16) /* * Return to the user task -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/182740: BTX halted on Jetway NF81 motherboard when RAID is enabled
On Sunday, October 06, 2013 7:28:31 am Julian Pidancet wrote: Number: 182740 Category: amd64 Synopsis: BTX halted on Jetway NF81 motherboard when RAID is enabled Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Sun Oct 06 11:30:00 UTC 2013 Closed-Date: Last-Modified: Originator: Julian Pidancet Release:8.2 Organization: Environment: Description: Just got this brand new motherboard with an AMD APU and an AMD chipset. Whenever I try to boot FreeBSD and AHCI or RAID is enabled in the BIOS, I am getting this message: BTX loader 1.00 BTX version is 1.02 int=000a err= efl=6402 eip=93e0 eax=534d4150 ebx=0001 ecx=0014 edx=534d4150 esi= edi=0004 ebp= esp=004e cs=0008 ds=0033 es=0033fs=0033 gs=0033 ss=0010 cs:eip=cf 83 f8 01 75 1a 16 87-86 1f 1e 0f a1 0f a0 0f a9 b8 00 a0 00 00 03 44-24 0c 8d 60 04 58 ff d0 ss:esp=00 f0 39 e7 00 f0 e3 21-80 ce 2e e8 00 f0 d2 ef 00 f0 00 e0 00 f0 f2 e6-00 f0 6e fe 00 f0 53 ff BTX halted It looks like to me the BTX is taking an Invalid TSS exception while executing an iret instruction. How-To-Repeat: I tried: - Booting from the install cdrom - Booting from an USB install disk - Booting from boot/pxeboot in PXE mode All exhibit the same issue. Fix: Selecting Legacy IDE mode in the BIOS configuration instead of AHCI/RAID. Ok, can you take this patch and use it to build an updated pxeboot and test if it fixes disk access with AHCI enabled? Index: boot/i386/btx/btx/btx.S === --- boot/i386/btx/btx/btx.S (revision 247010) +++ boot/i386/btx/btx/btx.S (working copy) @@ -41,6 +41,8 @@ .set PSL_RESERVED_DEFAULT,0x0002 .set PSL_T,0x0100 # Trap flag .set PSL_I,0x0200 # Interrupt enable flag + .set PSL_D,0x0400 # String instruction direction + .set PSL_NT,0x4000 # Nested task flag .set PSL_VM,0x0002 # Virtual 8086 mode flag .set PSL_AC,0x0004 # Alignment check flag /* @@ -611,8 +613,8 @@ pushl %ds # regs pushl %es pushfl # Save %eflags - cli # Disable interrupts - std # String ops dec + pushl $PSL_RESERVED_DEFAULT|PSL_D # Use clean %eflags with + popfl # string ops dec xorw %ax,%ax# Reset seg movw %ax,%ds# regs movw %ax,%es# (%ss is already 0) @@ -675,6 +677,7 @@ testl $V86F_FLAGS,%edx # User wants flags? jz rret_tramp.3 # No movl MEM_ESPR-0x3c,%eax # Read real mode flags + andl $~(PSL_T|PSL_NT),%eax # Clear unsafe flags movw %ax,-0x08(%esi)# Update user flags (low 16) /* * Return to the user task -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: FreeBSD and UEFI
On Friday, September 13, 2013 7:35:06 pm Neel Chauhan wrote: Hello FreeBSD users, Do you have any status on UEFI support for FreeBSD? I emailed Benno Rice, who was supposed to implement UEFI support for FreeBSD and he hasn't responded in the last few months. Do any of you know if FreeBSD supports UEFI booting yet? The work that was done is in Benno's projects branch in SVN. It has not been merged into HEAD. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: Accessing struct pthread from kernel
On Sunday, July 07, 2013 6:22:18 pm Davide Italiano wrote: On Sun, Jul 7, 2013 at 2:34 PM, Konstantin Belousov kostik...@gmail.com wrote: On Sat, Jul 06, 2013 at 01:22:05AM +0200, Davide Italiano wrote: Hi, as a preliminary step in the implementation of adaptive spinning for umtx, I'm switching the pthread/umtx code so that a thread that acquires a pthread_mutex writes the address of struct pthread in the owner field of the lock instead of the thread id (tid). This is because having struct pthread pointer allows easily to access informations of the thread, and makes easy to get the state of the thread exported from the kernel (once this will be implemented). For what concerns the libthr side, the internal function _get_curthread() goes into the TLS to obtain the struct field of curthread, so I'm done. OTOH, I'm quite unsure instead about how to get address of struct pthread for curthread from the kernel side (for example, in do_lock_umutex() sys/kern/kern_umtx.c). You should not, see below. I guess I need to write some MD code because the TLS is different on the various architecture supported in FreeBSD, and as a first step I focused on amd64. It looks like from the SDM that %%fs register points to the base of the TLS, so I think that accessing using curthread-td_pcb-pcb_fsbase (and then adding the proper offset to acces the right field) is a viable solution to do this. Am I correct? In particular what worries me is if the read of 'struct pthread' for curthread from the TLS register is atomic with respect to preemptions. Alternatively, is there an (easier way) to accomplish this task? Coupling the libthr thread structure and kernel makes the ABI cast in stone and avoids most possibilities of changing the libthr internals. The same is true for kernel accessing the userspace TLS area of the thread. If you want kernel-usermode communication of the thread run state, and possibly also a way to advisory prevent a preemption of the spinning usermode thread, you should create a dedicated parameter block communicated from usermode to kernel on thread creation. For the main thread, the block could be allocated by kernel by image activator, placed on the stack and its address passed to the usermode by auxv. Note that you cannot access the usermode from the context switch code. Wiring the corresponding page is very wasteful (think about a process with 10,000 threads) and still does not provide any guarantees since usermode can unmap or remap the range. You might see my 'fast sigprocmask' patches where somewhat similar idea was implemented. I think the tecnique you used for sigprocmask is neat and could be reused for sharing thread state between kernel and userland, with some modifications, thanks. That said, the problem I faced out before was slightly different. In order to implement adaptive spinning 'efficiently'[1], threads waiting for a lock held by some other thread should be able to access easily the state owner. If I understand the kernel locking code properly, to accomplish this, once a thread acquire a lock it writes the address of its struct thread in the owner field of the lock, so that other threads can easily access to his state. Now, it looks like applying such a tecnique for userspace is just impossible for the reasons you mentioned in your previous mail. The two alternatives that came up to the top of my mind are: 1) maintain an hashtable that keep track of the mapping tid-curthread, so that other thread perform a lookup on the hash table to get curthread access. If you have a good hash, this should be close to O(1) in the common case, so the lookup shouldn't be bad. However, you have to handle the race of a thread being added or removed to the table while you are spinning, and that seems more problematic / expensive. You only have to do a best effort though, so you could perhaps never remove items from the table (just mark them as dead somehow, though even that isn't completely safe). 2) having an array indexed by tid where the state is stuck so that other threads can check what is the state of the lock owner. This might not be a bad idea, though I'd possibly make it a hash table. It handles the remaining race from above since an exiting thread can just tag its tid with a dead state and you don't have to worry about threads trying to deref a free'd pointer. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: idle process keeping cpu 150% busy in freebsd 9.1-amd64
On Friday, May 31, 2013 10:47:34 am Kostas Oikonomou wrote: Thanks very much for the reply. Being new to FreeBSD, this still seems weird to me. (My background is Solaris.) On both machines, the core that's running at 150% in the case of the HP machine, and at 400% in the case of the Dell laptop, is causing the fans to come on. Would you call that idle? I'm worried that the cores will eventually be damaged. Do you have deeper Cx states enabled? By default FreeBSD will only enter C1. Try setting 'performance_cx_lowest=LOW' in /etc/rc.conf and either rebooting or running '/etc/rc.d/power_profile start' to see if that helps. You can see which Cx states are being used by running 'sysctl dev.cpu | grep cx_'. For example: dev.cpu.0.cx_supported: C1/3 C2/59 C3/93 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 324us dev.cpu.1.cx_supported: C1/3 C2/59 C3/93 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 300us dev.cpu.2.cx_supported: C1/3 C2/59 C3/93 dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_usage: 100.00% 0.00% 0.00% last 192us dev.cpu.3.cx_supported: C1/3 C2/59 C3/93 dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_usage: 100.00% 0.00% 0.00% last 157us This is on a machine with the default setup. After changing it to use the lowest setting: dev.cpu.0.cx_supported: C1/3 C2/59 C3/93 dev.cpu.0.cx_lowest: C3 dev.cpu.0.cx_usage: 5.84% 92.86% 1.28% last 145us dev.cpu.1.cx_supported: C1/3 C2/59 C3/93 dev.cpu.1.cx_lowest: C3 dev.cpu.1.cx_usage: 0.99% 94.92% 4.08% last 293us dev.cpu.2.cx_supported: C1/3 C2/59 C3/93 dev.cpu.2.cx_lowest: C3 dev.cpu.2.cx_usage: 0.45% 88.50% 11.04% last 174us dev.cpu.3.cx_supported: C1/3 C2/59 C3/93 dev.cpu.3.cx_lowest: C3 dev.cpu.3.cx_usage: 6.40% 86.89% 6.69% last 203us Another option is to run powerd which will throttle your CPUs down to lower clock speeds when they are idle. You can enable this by setting powerd_enable=YES in /etc/rc.conf and running '/etc/rc.d/powerd start'. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: idle process keeping cpu 150% busy in freebsd 9.1-amd64
On Friday, May 31, 2013 12:38:32 pm Kostas Oikonomou wrote: John, Thanks. I am trying your suggestions on my Dell laptop (Intel Core i7, 4 cores). First off, my /etc/rc.conf already had # powerd: adaptive speed while on AC power, adaptive while on battery power powerd_enable=YES powerd_flags=-a hiadaptive -b adaptive # set CPU frequency and powerd was running. With that, the output of sysctl was like what you sent (the default). Now my /etc/rc.conf reads # powerd: adaptive speed while on AC power, adaptive while on battery power powerd_enable=YES powerd_flags=-a hiadaptive -b adaptive # set CPU frequency # per John Baldwin email performance_cx_lowest=LOW and I rebooted. This is what sysctl shows now: [ko@hui-neng ~]$ sysctl dev.cpu | grep cx_ dev.cpu.0.cx_supported: C1/3 C2/205 C3/245 dev.cpu.0.cx_lowest: C3 dev.cpu.0.cx_usage: 18.65% 3.89% 77.44% last 2564us dev.cpu.1.cx_supported: C1/3 C2/205 C3/245 dev.cpu.1.cx_lowest: C3 dev.cpu.1.cx_usage: 18.05% 3.42% 78.52% last 2426us dev.cpu.2.cx_supported: C1/3 C2/205 C3/245 dev.cpu.2.cx_lowest: C3 dev.cpu.2.cx_usage: 16.73% 3.63% 79.62% last 6272us dev.cpu.3.cx_supported: C1/3 C2/205 C3/245 dev.cpu.3.cx_lowest: C3 dev.cpu.3.cx_usage: 15.78% 3.42% 80.78% last 2413us But still one core is at 400%, and the fan started running: The core will always look like it is running in top, even when it is asleep. That is just how FreeBSD accounts for idle CPU time. The only thing I was hoping would change is the fan having to run. You can try kldload'ing coretemp and seeing if the processor temperatures are different when deeper CX states are enabled (or when powerd is running) to see if it is having any affect on the temperatures in your box. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/178671: snd_hda stops working as soon as X starts
On Wednesday, May 15, 2013 3:35:01 pm Anton Shterenlikht wrote: Number: 178671 Category: amd64 Synopsis: snd_hda stops working as soon as X starts Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Wed May 15 19:40:02 UTC 2013 Closed-Date: Last-Modified: Originator: Anton Shterenlikht Release:FreeBSD 10.0-CURRENT amd64 Organization: University of Bristol Environment: System: FreeBSD mech-aslap239.men.bris.ac.uk 10.0-CURRENT FreeBSD 10.0- CURRENT #33 r250633: Tue May 14 20:11:05 BST 2013 root@mech- aslap239.men.bris.ac.uk:/usr/obj/usr/src/sys/BUZI amd64 Description: This is HP Compaq 6715s laptop. The sound card is: hdac0@pci0:0:20:2: class=0x040300 card=0x30c2103c chip=0x43831002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'SBx00 Azalia (Intel HDA)' class = multimedia subclass = HDA I have in the kernel: device sound # Generic sound driver (required) device snd_hda # Intel High Definition Audio In dmesg: hdac0: ATI SB600 HDA Controller mem 0xc000-0xc0003fff irq 16 at device 20.2 on pci0 Before X starts I can get sound via /dev/dsp, or play CDs with dd if=/dev/cd0 of=/dev/dspcd bs=2352 HOwever, as soon I start X, e.g. with xdm, or simply X -config /root/xorg.conf.new -retro I cannot get any sound anymore until a reboot. On the console I see lots of messages: hdac0: Unexpected unsolicited response from address 0: 0040 hdac0: Unexpected unsolicited response from address 0: 00400104 hdac0: Unexpected unsolicited response from address 0: 0001 hdac0: Unexpected unsolicited response from address 0: 000f hdac0: Unexpected unsolicited response from address 0: 410710f0 hdac0: Unexpected unsolicited response from address 0: 0010 hdac0: Unexpected unsolicited response from address 0: 0040 hdac0: Unexpected unsolicited response from address 0: 00400083 hdac0: Unexpected unsolicited response from address 0: hdac0: Unexpected unsolicited response from address 0: 04a12020 hdac0: Unexpected unsolicited response from address 0: 1727 hdac0: Unexpected unsolicited response from address 0: 0020 hdac0: Unexpected unsolicited response from address 0: 00400187 hdac0: Unexpected unsolicited response from address 0: 0002 hdac0: Unexpected unsolicited response from address 0: 0e03 hdac0: Unexpected unsolicited response from address 0: 0181302e hdac0: Unexpected unsolicited response from address 0: 1737 hdac0: Unexpected unsolicited response from address 0: 0020 hdac0: Unexpected unsolicited response from address 0: 00400301 hdac0: Unexpected unsolicited response from address 0: 0001 hdac0: Unexpected unsolicited response from address 0: 0002 hdac0: Unexpected unsolicited response from address 0: 4145f0f0 hdac0: Unexpected unsolicited response from address 0: 0010 hdac0: Unexpected unsolicited response from address 0: 0040 This sounds like the display driver is DMA'ing to the wrong place or writing to the wrong registers. Can you check the output of pciconf -lcb to make sure there are no collisions between BARs? Also, which GPU hardware/driver is in your laptop? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/178357: [patch] export CPU physical and virtual address sizes in sysctl oids using do_cpuid
rather than adding ad-hoc sysctls for certain fields. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: Fix amd64 ddb hardware watchpoints for SMP
On Thursday, May 16, 2013 2:41:27 am Konstantin Belousov wrote: The ddb use of hardware watchpoints on the x86 architectures is known to be lacking. There are at least two known problems. One is the improper interaction with the user-mode debuggers which use debug registers. Another is that ddb only loads the debug registers for the watchpoint into the CPU which is executing ddb code, not setting up non-current processors. Not touching the first problem for now, I want to fix the second issue, since as is, hardware watchpoints are useless on SMP. Patch below makes the stopped processors to load the debug registers after resuming from the stop handler, if directed by ddb. Also the patch contains two other commands for ddb which made my exprerience with debugger on amd64 better. The 'show pginfo[/p] addr' command dumps the vm_page_t information, either by vm_page address, or, if the /p modifier is specified, by the physical page address. The 'show phys2dmap addr' command translates physical address into the directly mapped address, which can be accessed from ddb then. This looks fine to me. It would be nice to fix i386 as well to be consistent. I would commit the new DDB commands as a separate patch from the watchpoint fixes. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/176474: kernel panic
On Wednesday, February 27, 2013 5:02:11 am Alexander Panyushkin wrote: Number: 176474 Category: amd64 Synopsis: kernel panic Confidential: no Severity: critical Priority: medium Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Wed Feb 27 10:10:00 UTC 2013 Closed-Date: Last-Modified: Originator: Alexander Panyushkin Release:FreeBSD 9.1-STABLE #0 r247338 Organization: home Environment: FreeBSD admin.local 9.1-STABLE FreeBSD 9.1-STABLE #0 r247338: Wed Feb 27 00:10:51 EET 2013 root@admin.local:/usr/obj/usr/src/sys/Kernel amd64 Description: There is a problem, after updating kernel have a kernel panic. Motheboard Intel#174; DG965WH On motheboard Asus not kernel panic. Does recompiling nvidia.ko fix the panic? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/176474: kernel panic
The following reply was made to PR amd64/176474; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: freebsd-amd64@freebsd.org Cc: Alexander Panyushkin vsi...@gmail.com, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/176474: kernel panic Date: Wed, 27 Feb 2013 10:56:29 -0500 On Wednesday, February 27, 2013 5:02:11 am Alexander Panyushkin wrote: Number: 176474 Category: amd64 Synopsis: kernel panic Confidential: no Severity: critical Priority: medium Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Wed Feb 27 10:10:00 UTC 2013 Closed-Date: Last-Modified: Originator: Alexander Panyushkin Release:FreeBSD 9.1-STABLE #0 r247338 Organization: home Environment: FreeBSD admin.local 9.1-STABLE FreeBSD 9.1-STABLE #0 r247338: Wed Feb 27 00:10:51 EET 2013 root@admin.local:/usr/obj/usr/src/sys/Kernel amd64 Description: There is a problem, after updating kernel have a kernel panic. Motheboard Intel#174; DG965WH On motheboard Asus not kernel panic. Does recompiling nvidia.ko fix the panic? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/175282: Freebsd 9.1 release amd64, mb Intel D525MW, not worked onboard ethernet.
On Monday, January 21, 2013 1:46:16 am lini...@freebsd.org wrote: Synopsis: Freebsd 9.1 release amd64, mb Intel D525MW, not worked onboard ethernet. Responsible-Changed-From-To: freebsd-bugs-freebsd-amd64 Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jan 21 06:45:53 UTC 2013 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=175282 Can you provide more details such as the pciconf -lcv output for the onboard ethernet? Also, it sounds like a driver attached to the device but didn't work? If so, can you provide ifconfig output? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/175091: Crash: Fatal trap 12: page fault while in kernel mode
On Monday, January 07, 2013 03:05:18 AM Rasmus Skaarup wrote: Number: 175091 Category: amd64 Synopsis: Crash: Fatal trap 12: page fault while in kernel mode Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Mon Jan 07 08:10:01 UTC 2013 Closed-Date: Last-Modified: Originator: Rasmus Skaarup Release:9.1-RELEASE Organization: Environment: FreeBSD thirdhost 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Description: On of my virtualized FreeBSD machines has been panic'ing two times within the last two weeks. After the first panic I ran freebsd-update and upgraded to 9.1-RELEASE succesfully. Today the machine panic'ed again. I have another virtualized FreeBSD machine running on the same host, and it does not exhibit this behaviour. Here is the output from dmesg, after reboot: Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x48 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80bd5139 stack pointer = 0x28:0xff81625536c0 frame pointer = 0x28:0xff8162553750 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 62083 (httpd) trap number = 12 panic: page fault cpuid = 2 KDB: stack backtrace: #0 0x809208a6 at kdb_backtrace+0x66 #1 0x808ea8be at panic+0x1ce #2 0x80bd8240 at trap_fatal+0x290 #3 0x80bd857d at trap_pfault+0x1ed #4 0x80bd8b9e at trap+0x3ce #5 0x80bc315f at calltrap+0x8 #6 0x80b41133 at vm_fault_hold+0x1b13 #7 0x80b41cc3 at vm_fault+0x73 #8 0x80bd84b4 at trap_pfault+0x124 #9 0x80bd8c6c at trap+0x49c #10 0x80bc315f at calltrap+0x8 Uptime: 13h6m22s * Can you enable crashdumps by setting 'dumpdev=AUTO' in /etc/rc.conf? Also, can you run 'gdb /boot/kernel/kernel' and then at the prompt run 'l *vm_fault_hold+0x1b13' and reply with the output? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/173235: Have received two crashes within 1 day after installing new packages: Fatal trap 12: page fault in kernel mode
On Thursday, November 08, 2012 2:32:32 pm Peter Wemm wrote: On Thu, Nov 8, 2012 at 10:29 AM, John Baldwin j...@freebsd.org wrote: On 10/31/12 8:50 AM, Tommy Sonne Alstrøm wrote: The following reply was made to PR amd64/173235; it has been noted by GNATS. From: =?ISO-8859-1?Q?Tommy_Sonne_Alstr=F8m?= to...@anakin.ws To: Andriy Gapon a...@freebsd.org Cc: bug-follo...@freebsd.org Subject: Re: amd64/173235: Have received two crashes within 1 day after installing new packages: Fatal trap 12: page fault in kernel mode Date: Wed, 31 Oct 2012 13:44:01 +0100 I'm very sorry, I just realized that I copied the 1st readout twice. The 2nd readout was like this Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x6 fault code = supervisor read data, page not present instruction pointer = 0x20:0x809da0cc stack pointer = 0x28:0xff8451f549b0 frame pointer = 0x28:0xff8451f54a40 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1068 (named) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0x808680fe at kdb_backtrace+0x5e #1 0x80832cb7 at panic+0x187 #2 0x80b185a0 at trap_fatal+0x290 #3 0x80b188e9 at trap_pfault+0x1f9 #4 0x80b18daf at trap+0x3df #5 0x80b0324f at calltrap+0x8 #6 0x809f75a7 at udp6_bind+0xa7 #7 0x808a152e at kern_bind+0xde #8 0x808a15a1 at sys_bind+0x41 #9 0x80b17e90 at amd64_syscall+0x4e0 #10 0x80b03537 at Xfast_syscall+0xf7 Uptime: 9h41m13s Dumping 3411 out of 16088 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Both of your panics involve faults where the bad pointer only has a single bit set. They are also in very different places. I suspect you are having a hardware failure (e.g. single-bit memory errors). Which ones are you looking at? A fault va of 0x20 and 0x6 is what I'd normally suspect of being a null pointer + structure member offset dereference. I must have misparsed 0x6 as 0x8. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/172854: 9.0R doesn't recognize HDD on intel C602 chipset
On Thursday, October 18, 2012 12:10:01 pm Jim Harris wrote: Intel C60x chipsets have 2 disk controllers - the SATA controller (which most people are familiar with), and an integrated SAS controller. The isci(4) driver for the SAS controller was added to FreeBSD in January - too late for 9.0, but did make it into 8.3 and will be in 9.1. My guess is the HDD in question is attached to the SAS controller, and not the SATA controller. I know that SuperMicro systems ship with the front disk slots connected to the SAS controller. On 8.3, can you run camcontrol devlist -v and check whether the disk in question is on an isciX or ahcichX bus? I think 9.0 didn't have the PCI ID for the onboard SATA in RAID mode either? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/172575: ioctl CAMGETPASSTHRU fails with mfi driver
On Wednesday, October 10, 2012 11:35:40 am John Klug wrote: Number: 172575 Category: amd64 Synopsis: ioctl CAMGETPASSTHRU fails with mfi driver Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Wed Oct 10 22:58:20 UTC 2012 Closed-Date: Last-Modified: Originator: John Klug Release:9.0 p3 Organization: UNISYS Environment: FreeBSD usrv-cse14.rsvl.unisys.com 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Thu Oct 4 15:55:24 CDT 2012 root@usrv- tsegp2:/usr/obj/freebsd/usr/src/sys/FREEBSD-amd64 amd64 Description: This problem causes sysutils/smartmontools to fail with the mfi driver peripheral devices. # camcontrol inquiry /dev/mfid0 camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed cam_lookup_pass: No such file or directory cam_lookup_pass: either the pass driver isn't in your kernel cam_lookup_pass: or mfid0 doesn't exist # kldstat Id Refs AddressSize Name 1 19 0x8020 1409420 kernel 21 0x8f20a000 17cf0isboot.ko 62 0x8f419000 6e90 mfi.ko 71 0x8f42 c3f mfip.ko 81 0x8f421000 132317 zfs.ko 91 0x8f554000 3001 opensolaris.ko usrv-cse14:/var/log# dmesg | grep mfid0 mfid0: MFI Logical Disk on mfi0 mfid0: 285568MB (584843264 sectors) RAID volume '' is optimal GEOM: mfid0: the secondary GPT header is not in the last LBA. # dmesg | grep mfid0 mfid0: MFI Logical Disk on mfi0 mfid0: 285568MB (584843264 sectors) RAID volume '' is optimal GEOM: mfid0: the secondary GPT header is not in the last LBA. # camcontrol inquiry /dev/pass2 pass2: TOSHIBA MBF2300RC DA06 Fixed Uninstalled SCSI-6 device pass2: Serial Number EB03PB302RPS pass2: 150.000MB/s transfers # smartd -d --configfile=/var/etc/smartd.conf --logfacility=local5 smartd 5.42 2011-10-20 r3458 [FreeBSD 9.0-RELEASE-p3 amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net Opened configuration file /var/etc/smartd.conf Configuration file /var/etc/smartd.conf parsed. Device: /dev/mfid0, unable to autodetect device type Device: /dev/mfid1, unable to autodetect device type Device: /dev/mfid2, unable to autodetect device type Device: /dev/mfid3, unable to autodetect device type Device: /dev/mfid4, unable to autodetect device type Device: /dev/mfid5, unable to autodetect device type Device: /dev/mfid6, unable to autodetect device type Device: /dev/mfid7, unable to autodetect device type Unable to monitor any SMART enabled devices. Try debug (-d) option. Exiting... This problem makes it difficult to relate zpool devices to the device serial number and SMART information. mfidX are logical volumes, not physical drives. passX are physical drives and that is what smartd needs to monitor. This is not a bug, this is just how you have to use smartd with drives behind an mfi(4) controller. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
On Wednesday, September 05, 2012 4:14:48 pm Stefano Marinelli wrote: Number: 171355 Category: amd64 Synopsis: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Wed Sep 05 20:20:03 UTC 2012 Closed-Date: Last-Modified: Originator: Stefano Marinelli Release:9.1-rc1 Organization: Environment: impossible to obtain - machine stops at boot Description: Hi, I tried to install FreeBSD 9.1-rc1 (amd64 and i386, no difference) on the HP Pavilion g6 2147sl. The installation disk's loader runs, the kernel starts to boot then hangs. No strange messages come out (even with verbose output turned on) and the boot process stops there. Everything seems to be recognised in a proper way (usb3, ahci, re0 network card, etc). I've done some tests (thanks to the suggestions on the ##freebsd irc channel's people) but no success and no further information to add. I can't even go to ddb. But if I remove the cd from the tray, the status change gets detected and the kernel prints something on the screen. 9.0 can boot, but it's almost unusable as both the re0 and the wifi interface aren't detected and there isn't any support for power management so fans are running all the time. It seems to stop after USB recognition. But I guess it's already finished with usb... Does 9.1 fail to recognize the on-board disk? I've seen several reports of 9.1 failing to discover certain SSD's but working ok with spinning disks on IBM laptops where 9.0 worked fine. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
The following reply was made to PR amd64/171355; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: freebsd-amd64@freebsd.org Cc: Stefano Marinelli stef...@dragas.it, freebsd-gnats-sub...@freebsd.org, Alexander Motin m...@freebsd.org, r...@freebsd.org Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl Date: Thu, 6 Sep 2012 14:10:12 -0400 On Wednesday, September 05, 2012 4:14:48 pm Stefano Marinelli wrote: Number: 171355 Category: amd64 Synopsis: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Wed Sep 05 20:20:03 UTC 2012 Closed-Date: Last-Modified: Originator: Stefano Marinelli Release:9.1-rc1 Organization: Environment: impossible to obtain - machine stops at boot Description: Hi, I tried to install FreeBSD 9.1-rc1 (amd64 and i386, no difference) on the HP Pavilion g6 2147sl. The installation disk's loader runs, the kernel starts to boot then hangs. No strange messages come out (even with verbose output turned on) and the boot process stops there. Everything seems to be recognised in a proper way (usb3, ahci, re0 network card, etc). I've done some tests (thanks to the suggestions on the ##freebsd irc channel's people) but no success and no further information to add. I can't even go to ddb. But if I remove the cd from the tray, the status change gets detected and the kernel prints something on the screen. 9.0 can boot, but it's almost unusable as both the re0 and the wifi interface aren't detected and there isn't any support for power management so fans are running all the time. It seems to stop after USB recognition. But I guess it's already finished with usb... Does 9.1 fail to recognize the on-board disk? I've seen several reports of 9.1 failing to discover certain SSD's but working ok with spinning disks on IBM laptops where 9.0 worked fine. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: Bug Report: IBM x3650M4 (32GB, 2x4-core Xeon E5-2600, IBM ServeRaid M5110e): fails in install with NMI
On Monday, August 27, 2012 4:38:17 pm Mike A wrote: IBM x3650M4 (32GB, 2x4-core Xeon E5-2600, IBM ServeRaid M5110e) I just got handed 4 of the subject boxes with instructions put 'em to work. Naturally I tried FreeBSD first, on one of the machines. Boot from the 9.0 AMD64 boot-only install CD fails. Things look fine until the last several lines of the (verbose enabled) boot sequence, which (from an insufficiently-wide phone camera capture) are: mpt0: LSILogic SAS/SATA Adapter port 0x3000-0x[lost off right edge of phone] xc5d0-0xc5de irq 34 at device 0.0 on pci[lost] mpt0: attempting to allocate 1 MSI vectors (1 su[lost] msi: routing MSI IRQ 256 to local APIC 0 vector [lost] mpt0: using IRQ 256 for MSI mpt0: soft reset failed, device not running NMI ISA 2c, EISA 0 NMI ... going to debugger mpt0: hard reset failed Does setting 'hint.mpt.0.msi_enable=0' in the loader make a difference? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: Bug Report: IBM x3650M4 (32GB, 2x4-core Xeon E5-2600, IBM ServeRaid M5110e): fails in install with NMI
On Tuesday, August 28, 2012 10:05:07 am Mike A wrote: On Tue, Aug 28, 2012 at 09:34:14AM -0400, John Baldwin wrote: On Monday, August 27, 2012 4:38:17 pm Mike A wrote: IBM x3650M4 (32GB, 2x4-core Xeon E5-2600, IBM ServeRaid M5110e) I just got handed 4 of the subject boxes with instructions put 'em to work. Naturally I tried FreeBSD first, on one of the machines. Boot from the 9.0 AMD64 boot-only install CD fails. Things look fine until the last several lines of the (verbose enabled) boot sequence, which (from an insufficiently-wide phone camera capture) are: mpt0: LSILogic SAS/SATA Adapter port 0x3000-0x[lost off right edge of phone] xc5d0-0xc5de irq 34 at device 0.0 on pci[lost] mpt0: attempting to allocate 1 MSI vectors (1 su[lost] msi: routing MSI IRQ 256 to local APIC 0 vector [lost] mpt0: using IRQ 256 for MSI mpt0: soft reset failed, device not running NMI ISA 2c, EISA 0 NMI ... going to debugger mpt0: hard reset failed Does setting 'hint.mpt.0.msi_enable=0' in the loader make a difference? Thanks VERY MUCH (and come collect your steak dinner at Cattlemen's Cafe in OKC, next time you're in the area) for the very quick response. I will be happy to try that, but need guidance. This is an install from CD (burned from FreeBSD-9.1-RC1-amd64-disc1.iso), and I don't know how to insert a loader hint in that process. When the loader menu pops up, choose the escape to loader prompt option, then type 'set hint.mpt.0.msi_enable=0' followed by 'boot'. There's no guarantee this will help, btw, just something to try out first. If that doesn't work, you can also try setting 'machdep.kdb_on_nmi=0' using the same trick. If that still doesn't help, please boot another OS that does and get the output of 'lspci -v' or 'pciconf -lvb' or equivalent so we can see exactly which mpt adapter it is. I think there is one class of mpt(4) cards that we do not yet support properly. Ah, yes, this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=149220 I think this may in fact be your adapter. This was fixed after 9.0, so try a 9.1-RC1 install disk instead and see if it works better. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/171108: Kernel panic
The following reply was made to PR amd64/171108; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: freebsd-amd64@freebsd.org, gleb...@freebsd.org Cc: Ivan Goryushkin animage.n...@gmail.com, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/171108: Kernel panic Date: Mon, 27 Aug 2012 10:28:59 -0400 On Monday, August 27, 2012 12:12:37 am Ivan Goryushkin wrote: #3 0x80936e76 in dblfault_handler (frame=Variable frame is not available. ) at /usr/src/sys/amd64/amd64/trap.c:852 #4 0x8091eefd in Xdblfault () at /usr/src/sys/amd64/amd64/exception.S:284 #5 0x8073b772 in ipfw_chk (args=0xff8231ee1190) at /usr/src/sys/netinet/ipfw/ip_fw2.c:1168 #6 0x8074161a in ipfw_check_hook (arg=Variable arg is not available. ) at /usr/src/sys/netinet/ipfw/ip_fw_pfil.c:137 #7 0x806ca55c in pfil_run_hooks (ph=Variable ph is not available. ) at /usr/src/sys/net/pfil.c:82 #8 0x8074a34a in ip_output (m=0xff019e941b00, opt=Variable opt is not available. ) at /usr/src/sys/netinet/ip_output.c:511 #9 0x807b8236 in tcp_output (tp=0xff02199b8760) at /usr/src/sys/netinet/tcp_output.c:1230 #10 0x807bbc7f in tcp_mtudisc (inp=0xff0219a89bd0, errno=Variable errno is not available. ) at tcp_offload.h:282 #11 0x807b912c in tcp_output (tp=0xff02199b8760) at /usr/src/sys/netinet/tcp_output.c:1291 #12 0x807bbc7f in tcp_mtudisc (inp=0xff0219a89bd0, errno=Variable errno is not available. This looks to have been fixed in HEAD a few weeks ago: http://svnweb.freebsd.org/base?view=revisionrevision=238516 Gleb, were you planning on MFC'ing this to 8 or 9? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/170487: Thinkpad X61s cannot boot 9.1-BETA1
On Wednesday, August 08, 2012 02:46:39 PM Per olof Ljungmark wrote: Number: 170487 Category: amd64 Synopsis: Thinkpad X61s cannot boot 9.1-BETA1 Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Wed Aug 08 18:50:01 UTC 2012 Closed-Date: Last-Modified: Originator: Per olof Ljungmark Release:9.1-BETA1 Organization: Environment: 9.1-BETA1 amd64 Description: Thinkpad X61s is unable to boot 9.1-BETA1. A verbose boot, last line is acpi_acad: acline initialization done, tried 1 times Can you capture more lines from a verbose dmesg? Also, how are you booting? Are you booting from a CD or netbooting via PXE? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/170487: Thinkpad X61s cannot boot 9.1-BETA1
The following reply was made to PR amd64/170487; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: freebsd-amd64@freebsd.org Cc: Per olof Ljungmark p...@intersonic.se, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/170487: Thinkpad X61s cannot boot 9.1-BETA1 Date: Tue, 14 Aug 2012 08:17:51 -0400 On Wednesday, August 08, 2012 02:46:39 PM Per olof Ljungmark wrote: Number: 170487 Category: amd64 Synopsis: Thinkpad X61s cannot boot 9.1-BETA1 Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Wed Aug 08 18:50:01 UTC 2012 Closed-Date: Last-Modified: Originator: Per olof Ljungmark Release:9.1-BETA1 Organization: Environment: 9.1-BETA1 amd64 Description: Thinkpad X61s is unable to boot 9.1-BETA1. A verbose boot, last line is acpi_acad: acline initialization done, tried 1 times Can you capture more lines from a verbose dmesg? Also, how are you booting? Are you booting from a CD or netbooting via PXE? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/169779: [patch] powerd doesn't honor the -n flag
On Tuesday, July 10, 2012 10:48:51 pm Axel Gonzalez wrote:
Number: 169779
Category: amd64
Synopsis: [patch] powerd doesn't honor the -n flag
Confidential: no
Severity: serious
Priority: low
Responsible:freebsd-amd64
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Wed Jul 11 02:50:10 UTC 2012
Closed-Date:
Last-Modified:
Originator: Axel Gonzalez
Release:9.0-RELEASE-p2
Organization:
Environment:
FreeBSD moonlight 9.0-RELEASE-p2 FreeBSD 9.0-RELEASE-p2 #0: Tue Jun 12
02:12:57 CDT 2012 toor@moonlight:/usr/obj/usr/src/sys/LXCORE964 amd64
Description:
powerd never initializes the variable that keeps the status of the line
status. This variable defaults to 0 (with the compiler? with the arch?) and
results in powerd using the AC profile.
This is a problem, since at start it says it is in unkown status, but
doesn't respect the -n argument.
Note: since the variable is not initialized, it can lead to other unexpected
behaviour.
How-To-Repeat:
This should use the adaptive profile specified by -n, but uses hiadaptive
# /usr/sbin/powerd -i 50 -r 80 -M 1800 -v -p 1000 -n adaptive
powerd: unable to determine AC line status
CPU frequency is above user-defined maximum; changing frequency to 1795 MHz
load 15%, current freq 1795 MHz ( 0), wanted freq 2094 MHz
Fix:
Initialize the variable
--- powerd.c.orig 2012-07-10 21:21:07.882970887 -0500
+++ powerd.c2012-07-10 21:22:29.292974203 -0500
@@ -278,6 +278,7 @@
acline_init(void)
{
acline_mib_len = 4;
+acline_status = SRC_UNKNOWN;
if (sysctlnametomib(ACPIAC, acline_mib, acline_mib_len) == 0) {
acline_mode = ac_sysctl;
I suspect this is correct, but cc'ing acpi@ to see if anyone there has any
comments.
--
John Baldwin
___
freebsd-amd64@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/169779: [patch] powerd doesn't honor the -n flag
The following reply was made to PR amd64/169779; it has been noted by GNATS.
From: John Baldwin j...@freebsd.org
To: freebsd-amd64@freebsd.org
Cc: Axel Gonzalez l...@e-shell.net,
freebsd-gnats-sub...@freebsd.org,
a...@freebsd.org
Subject: Re: amd64/169779: [patch] powerd doesn't honor the -n flag
Date: Thu, 12 Jul 2012 07:40:09 -0400
On Tuesday, July 10, 2012 10:48:51 pm Axel Gonzalez wrote:
Number: 169779
Category: amd64
Synopsis: [patch] powerd doesn't honor the -n flag
Confidential: no
Severity: serious
Priority: low
Responsible:freebsd-amd64
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Wed Jul 11 02:50:10 UTC 2012
Closed-Date:
Last-Modified:
Originator: Axel Gonzalez
Release:9.0-RELEASE-p2
Organization:
Environment:
FreeBSD moonlight 9.0-RELEASE-p2 FreeBSD 9.0-RELEASE-p2 #0: Tue Jun 12
02:12:57 CDT 2012 toor@moonlight:/usr/obj/usr/src/sys/LXCORE964 amd64
Description:
powerd never initializes the variable that keeps the status of the line
status. This variable defaults to 0 (with the compiler? with the arch?) and
results in powerd using the AC profile.
This is a problem, since at start it says it is in unkown status, but
doesn't respect the -n argument.
Note: since the variable is not initialized, it can lead to other unexpected
behaviour.
How-To-Repeat:
This should use the adaptive profile specified by -n, but uses hiadaptive
# /usr/sbin/powerd -i 50 -r 80 -M 1800 -v -p 1000 -n adaptive
powerd: unable to determine AC line status
CPU frequency is above user-defined maximum; changing frequency to 1795 MHz
load 15%, current freq 1795 MHz ( 0), wanted freq 2094 MHz
Fix:
Initialize the variable
--- powerd.c.orig 2012-07-10 21:21:07.882970887 -0500
+++ powerd.c2012-07-10 21:22:29.292974203 -0500
@@ -278,6 +278,7 @@
acline_init(void)
{
acline_mib_len = 4;
+acline_status = SRC_UNKNOWN;
if (sysctlnametomib(ACPIAC, acline_mib, acline_mib_len) == 0) {
acline_mode = ac_sysctl;
I suspect this is correct, but cc'ing acpi@ to see if anyone there has any
comments.
--
John Baldwin
___
freebsd-amd64@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: XSAVEOPT
On Sunday, July 08, 2012 11:02:25 am Konstantin Belousov wrote: Please find at http://people.freebsd.org/~kib/misc/xsaveopt.1.patch a patch to finally add suport for using XSAVEOPT for our amd64 context switch code. See Intel SDM for description of the XSAVEOPT instruction. Summary is that the instruction allows to not write parts of the FPU state which was not touched by the thread. Context switch then would write less to the PCB when thread is moved out from CPU. This is mainly to facilitate the ever-growing size of the FPU register file, in particular, AVX/YMM registers. Normal applications do not touch YMM, so saving them on each context switch if FPU was used is waste. Main complication is that any consumer of the ucontext_t still expect to see fully populated machine state, including the extended states which were not saved. Since CPU only avoids save when corresponding state is pristine, we can use the copy of initial state. CPUID provides an enumerator that allows OS to easily pick up neccesary area and copy over. I tried hard, but was unable to measure any statistically significant difference in the context switch times between XSAVE and XSAVEOPT using lmbench lat_ctx, on Core i7 2600K. Hmm, I thought one of the ideas of xsaveopt was to let you just always execute it during a context switch and dispense with the need for using the CR0_TS flag at all? Maybe that isn't true though. It would seem rather silly to switch out the state if you don't need to (when preempting a thread that uses the FPU to run a thread that doesn't and then switching back for example). -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: bin/167128: ps(1): 'ps -e' or 'pw -wwe' doesn't display the environment of 32-bit processes (amd64-specific)
On Saturday, April 21, 2012 1:39:36 am lini...@freebsd.org wrote: Old Synopsis: 'ps -e' or 'pw -wwe' doesn't display the environment of 32-bit processes New Synopsis: ps(1): 'ps -e' or 'pw -wwe' doesn't display the environment of 32-bit processes (amd64-specific) Responsible-Changed-From-To: freebsd-amd64-freebsd-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Sat Apr 21 05:38:25 UTC 2012 Responsible-Changed-Why: I'm not really sure how to classify this, but it isn't hardware-related, so move it over to bin/. Well, the 32-on-64 bit is somewhat amd64-specific (though we have that same issue on powerpc now). However, can the submitter test this on 9-stable? There were some changes MFC'd after 9.0 that might fix this. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/166442: nfsd error when not compiled into kernel
On Tuesday, March 27, 2012 8:02:18 am Beeblebrox wrote: Number: 166442 Category: amd64 Synopsis: nfsd error when not compiled into kernel Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Tue Mar 27 12:10:11 UTC 2012 Closed-Date: Last-Modified: Originator: Beeblebrox Release:9.0-STABLE Organization: Environment: FreeBSD 9.0-STABLE #0 r233503: Mon Mar 26 23:53:01 EEST 2012 Description: In Kernel config file, options: options NFSCLIENT # Network Filesystem Client #optionsNFSSERVER # Network Filesystem Server #optionsNFSLOCKD# Network Lock Manager options NFS_ROOT# NFS usable as /, requires NFSCLIENT buildkernel with these settings results in a kernel which CANNOT KLDLOAD nfsd, and result in error message: Version Mismatch or Exec Format Error Commenting out NFSCLIENT results in a kernel which is able to load and start nfsd, while the PXE terminal client is still able to boot and mount root from NFS (provided nfscl_enable=YES is specified in the /boot/loader.conf of PXE's root). so NFS_ROOT does not necessarily require NFSCLIENT, but NFSCLIENT certainly seems to require NFSSERVER. Yes, you should be using NFSCL and NFSD instead of NFSCLIENT and NFSSERVER now. 9 includes a new NFS client and server implementation that include NFSv4 support (and have cleaner code). GENERIC changed between 8 and 9 to switch to the new client and server, but it seems you are using an unmodified kernel config from 8 on 9? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/166229: [boot] Unable to install FreeBSD 9 on Acer Extensa 5220
On Monday, March 26, 2012 10:20:12 am Robert Peters wrote: The following reply was made to PR amd64/166229; it has been noted by GNATS. From: Robert Peters r2p2...@googlemail.com To: bug-follo...@freebsd.org, r2p2...@googlemail.com Cc: Subject: Re: amd64/166229: [boot] Unable to install FreeBSD 9 on Acer Extensa 5220 Date: Mon, 26 Mar 2012 16:14:57 +0200 It seems that I am unable to do that. Documentation does not describe well enough for me, how to enter the ddb. And there is still the open question if the ddb is enabled in the live cd kernel. If not it would be hard to enable it without booting it. I will try all what is needed if it is documented well enough for a potato (me). Hmm, normally on the video console one would just use Ctrl-Alt-Esc. However, it may very well be that we do not include DDB in the release kernels. :( -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/166442: nfsd error when not compiled into kernel
The following reply was made to PR amd64/166442; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: freebsd-amd64@freebsd.org Cc: Beeblebrox zap...@berentweb.com, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/166442: nfsd error when not compiled into kernel Date: Tue, 27 Mar 2012 10:44:56 -0400 On Tuesday, March 27, 2012 8:02:18 am Beeblebrox wrote: Number: 166442 Category: amd64 Synopsis: nfsd error when not compiled into kernel Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Tue Mar 27 12:10:11 UTC 2012 Closed-Date: Last-Modified: Originator: Beeblebrox Release:9.0-STABLE Organization: Environment: FreeBSD 9.0-STABLE #0 r233503: Mon Mar 26 23:53:01 EEST 2012 Description: In Kernel config file, options: options NFSCLIENT # Network Filesystem Client #optionsNFSSERVER # Network Filesystem Server #optionsNFSLOCKD# Network Lock Manager options NFS_ROOT# NFS usable as /, requires NFSCLIENT buildkernel with these settings results in a kernel which CANNOT KLDLOAD nfsd, and result in error message: Version Mismatch or Exec Format Error Commenting out NFSCLIENT results in a kernel which is able to load and start nfsd, while the PXE terminal client is still able to boot and mount root from NFS (provided nfscl_enable=YES is specified in the /boot/loader.conf of PXE's root). so NFS_ROOT does not necessarily require NFSCLIENT, but NFSCLIENT certainly seems to require NFSSERVER. Yes, you should be using NFSCL and NFSD instead of NFSCLIENT and NFSSERVER now. 9 includes a new NFS client and server implementation that include NFSv4 support (and have cleaner code). GENERIC changed between 8 and 9 to switch to the new client and server, but it seems you are using an unmodified kernel config from 8 on 9? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/164773: [boot] 9.0 amd64 fails to boot on HP DL145 G3 [regression]
On Saturday, March 17, 2012 10:54:02 am Kai Gallasch wrote: Am 15.03.2012 um 14:33 schrieb John Baldwin: On Wednesday, March 14, 2012 6:40:03 am Kai Gallasch wrote: The following reply was made to PR amd64/164773; it has been noted by GNATS. From: Kai Gallasch galla...@free.de To: bug-follo...@freebsd.org, jsh...@hermetek.com Cc: Subject: Re: amd64/164773: [boot] 9.0 amd64 fails to boot on HP DL145 G3 [regression] Date: Wed, 14 Mar 2012 11:25:10 +0100 Booting the DL145 G3 with disabled ehci in GENERIC kernel changes = nothing, the boot process still times out with mount waiting for: usbus1 usbus0 Hmm, if you are still able to try, it would be interesting to build a kernel without USB at all to see if it can boot ok. Also, it might be good to break into DDB in a kernel with USB enabled and run 'show intrcnt' to see if the USB devices are seeing any interrupts. I installed 8.3 on this server and did a makeworld into 9.0 REL (GENERIC kernel without USB support) Now the bootup from drom disk stops with the message: Entropy harvesting: interrupts ethernet point_to_point and I cannot enter DDB (vga console, ctrl-alt-esc), although it is compiled into the kernel. However. I have the option to boot into single-user, before Entropy harvesting: interrupts ethernet point_to_point shows up. FYI: Additionally I tried to boot the 9.0-RELEASE-AMD64 memstick on another HP/Compaq server (DL385 G2) and the bootup also stops with the same mount waiting for: usbus1 usbus0 message, as the DL145G3 does. Is DDB active on the 9.0-RELEASE-AMD64 memstick? Hmm, I'm not sure if it is. If it isn't, you can build a 9.0 kernel that contains DDB and replace the kernel image on the memstick with that from another machine. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/164773: [boot] 9.0 amd64 fails to boot on HP DL145 G3 [regression]
On Wednesday, March 14, 2012 6:40:03 am Kai Gallasch wrote: The following reply was made to PR amd64/164773; it has been noted by GNATS. From: Kai Gallasch galla...@free.de To: bug-follo...@freebsd.org, jsh...@hermetek.com Cc: Subject: Re: amd64/164773: [boot] 9.0 amd64 fails to boot on HP DL145 G3 [regression] Date: Wed, 14 Mar 2012 11:25:10 +0100 Booting the DL145 G3 with disabled ehci in GENERIC kernel changes = nothing, the boot process still times out with mount waiting for: usbus1 usbus0 Hmm, if you are still able to try, it would be interesting to build a kernel without USB at all to see if it can boot ok. Also, it might be good to break into DDB in a kernel with USB enabled and run 'show intrcnt' to see if the USB devices are seeing any interrupts. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/164773: [boot] 9.0 amd64 fails to boot on HP DL145 G3 [regression]
The following reply was made to PR amd64/164773; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: bug-follo...@freebsd.org, jsh...@hermetek.com Cc: Subject: Re: amd64/164773: [boot] 9.0 amd64 fails to boot on HP DL145 G3 [regression] Date: Tue, 21 Feb 2012 14:04:33 -0500 There aren't any hints to disable USB I'm afraid. Can you instead build a kernel that doesn't include 'device ehci' and see if that boots ok? Also, can you provide the output of 'pciconf -lv'? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/164036: Moused fails on 9_0_RELENG
On Tuesday, January 17, 2012 10:58:07 pm Justin Smith wrote: John, I tried it the way you suggested but I doesn't work - 'iasl acpi_dsdt.dsl' --- http://paste.pocoo.org/show/536531/ Hmmm, your AML is very broken. :( However, I think I might have a workaround for your case. Can you please try http://www.freebsd.org/~jhb/patches/acpi_ps2_mouse.patch? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/164036: Moused fails on 9_0_RELENG
The following reply was made to PR amd64/164036; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: Justin Smith freebsd.us...@gmail.com Cc: freebsd-amd64@freebsd.org, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/164036: Moused fails on 9_0_RELENG Date: Fri, 20 Jan 2012 11:14:40 -0500 On Tuesday, January 17, 2012 10:58:07 pm Justin Smith wrote: John, I tried it the way you suggested but I doesn't work - 'iasl acpi_dsdt.dsl' --- http://paste.pocoo.org/show/536531/ Hmmm, your AML is very broken. :( However, I think I might have a workaround for your case. Can you please try http://www.freebsd.org/~jhb/patches/acpi_ps2_mouse.patch? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/164036: Moused fails on 9_0_RELENG
On Saturday, January 14, 2012 4:20:15 am Justin Smith wrote: On Sat, Jan 14, 2012 at 1:12 AM, Justin Smith freebsd.us...@gmail.com wrote: Err, not a BIOS setting, but actually editing the AML. Assuming you edited the ASUS AML, can you show me a diff of the original and modified AML? -- John Baldwin Okay, will do that tomorrow, its 1:12 am, need some sleep. Have a great day. I tried editing BIOS with AMITOOLS but it failed and I wasn't able to boot the box, had to reset the BIOS in order to boot again. I have limited expertise and I think I wont be able to do this. What has changed between 8_2_RELENG and 9_0_RELENG? I used same hardware for 8_2_RELENG and 8-STABLE, the mouse worked there. You don't need to edit the BIOS. You take the output of acpidump -d, edit that in a text editor as I had suggested earlier, then follow the instructions in the acpi(4) man page (OVERRIDING YOUR BIOS BYTECODE section) to compile the edited version and use it instead of the one your BIOS provides. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/164036: Moused fails on 9_0_RELENG
The following reply was made to PR amd64/164036; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: Justin Smith freebsd.us...@gmail.com Cc: freebsd-amd64@freebsd.org, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/164036: Moused fails on 9_0_RELENG Date: Tue, 17 Jan 2012 10:17:17 -0500 On Saturday, January 14, 2012 4:20:15 am Justin Smith wrote: On Sat, Jan 14, 2012 at 1:12 AM, Justin Smith freebsd.us...@gmail.com wrote: Err, not a BIOS setting, but actually editing the AML. Assuming you edited the ASUS AML, can you show me a diff of the original and modified AML? -- John Baldwin Okay, will do that tomorrow, its 1:12 am, need some sleep. Have a great day. I tried editing BIOS with AMITOOLS but it failed and I wasn't able to boot the box, had to reset the BIOS in order to boot again. I have limited expertise and I think I wont be able to do this. What has changed between 8_2_RELENG and 9_0_RELENG? I used same hardware for 8_2_RELENG and 8-STABLE, the mouse worked there. You don't need to edit the BIOS. You take the output of acpidump -d, edit that in a text editor as I had suggested earlier, then follow the instructions in the acpi(4) man page (OVERRIDING YOUR BIOS BYTECODE section) to compile the edited version and use it instead of the one your BIOS provides. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/164036: Moused fails on 9_0_RELENG
On Thursday, January 12, 2012 9:19:32 pm Justin Smith wrote: acpidump -d - http://paste.pocoo.org/show/534042/ Hmm, what an odd system. It has two different sets of PS/2 keyboard/mouse devices (PSKE and PSMS vs PS2K and PS2M). Still, it's not clear why neither of those worked. Can you get devinfo -vr output? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/164036: Moused fails on 9_0_RELENG
The following reply was made to PR amd64/164036; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: Justin Smith freebsd.us...@gmail.com Cc: freebsd-amd64@freebsd.org, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/164036: Moused fails on 9_0_RELENG Date: Fri, 13 Jan 2012 08:08:03 -0500 On Thursday, January 12, 2012 9:19:32 pm Justin Smith wrote: acpidump -d - http://paste.pocoo.org/show/534042/ Hmm, what an odd system. It has two different sets of PS/2 keyboard/mouse devices (PSKE and PSMS vs PS2K and PS2M). Still, it's not clear why neither of those worked. Can you get devinfo -vr output? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/164036: Moused fails on 9_0_RELENG
On Friday, January 13, 2012 9:20:53 am Justin Smith wrote: Yeah, its strange for sure. But I have this issue on two different systems with different hardware (ASUS board BIOSTAR Board). devinfo -vr : http://paste.pocoo.org/show/534240/ Hmm. So the problem is your BIOS putting the keyboard resources on the PS/2 port. You can fix this by editing your AML and moving the IO Port resources out of _CRS for the PS2M device and moving them to the PS2K device instead. However, fixing it automatically would be a bigger pain as we would need to patch both the atkbdc and psmcpnp drivers to cooperate to move the I/O ports over. We already have a similar hack for handling IRQ 12. We should perhaps expand that further so that we have atkbdc somehow attach to both PS/2 devices and merge any resources into a single logical device. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/164036: Moused fails on 9_0_RELENG
The following reply was made to PR amd64/164036; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: Justin Smith freebsd.us...@gmail.com Cc: freebsd-amd64@freebsd.org, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/164036: Moused fails on 9_0_RELENG Date: Fri, 13 Jan 2012 10:18:45 -0500 On Friday, January 13, 2012 9:20:53 am Justin Smith wrote: Yeah, its strange for sure. But I have this issue on two different systems with different hardware (ASUS board BIOSTAR Board). devinfo -vr : http://paste.pocoo.org/show/534240/ Hmm. So the problem is your BIOS putting the keyboard resources on the PS/2 port. You can fix this by editing your AML and moving the IO Port resources out of _CRS for the PS2M device and moving them to the PS2K device instead. However, fixing it automatically would be a bigger pain as we would need to patch both the atkbdc and psmcpnp drivers to cooperate to move the I/O ports over. We already have a similar hack for handling IRQ 12. We should perhaps expand that further so that we have atkbdc somehow attach to both PS/2 devices and merge any resources into a single logical device. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/164036: Moused fails on 9_0_RELENG
The following reply was made to PR amd64/164036; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: Justin Smith freebsd.us...@gmail.com Cc: freebsd-amd64@freebsd.org, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/164036: Moused fails on 9_0_RELENG Date: Fri, 13 Jan 2012 11:54:36 -0500 On Friday, January 13, 2012 11:17:35 am Justin Smith wrote: On Fri, Jan 13, 2012 at 11:18 PM, John Baldwin j...@freebsd.org wrote: On Friday, January 13, 2012 9:20:53 am Justin Smith wrote: Yeah, its strange for sure. But I have this issue on two different systems with different hardware (ASUS board BIOSTAR Board). devinfo -vr : http://paste.pocoo.org/show/534240/ Hmm. So the problem is your BIOS putting the keyboard resources on the PS/2 port. You can fix this by editing your AML and moving the IO Port resources out of _CRS for the PS2M device and moving them to the PS2K device instead. However, fixing it automatically would be a bigger pain as we would need to patch both the atkbdc and psmcpnp drivers to cooperate to move the I/O ports over. We already have a similar hack for handling IRQ 12. We should perhaps expand that further so that we have atkbdc somehow attach to both PS/2 devices and merge any resources into a single logical device. -- John Baldwin Been there done that (ASUS board AML), doesn't work. I have no settings for PS2M to PS2K on BIOSTAR BIOS. Err, not a BIOS setting, but actually editing the AML. Assuming you edited the ASUS AML, can you show me a diff of the original and modified AML? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/164036: Moused fails on 9_0_RELENG
The following reply was made to PR amd64/164036; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: freebsd-amd64@freebsd.org Cc: Justin freebsd.us...@gmail.com, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/164036: Moused fails on 9_0_RELENG Date: Thu, 12 Jan 2012 07:39:26 -0500 On Wednesday, January 11, 2012 11:39:24 pm Justin wrote: Number: 164036 Category: amd64 Synopsis: Moused fails on 9_0_RELENG Confidential: no Severity: critical Priority: medium Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Thu Jan 12 04:40:09 UTC 2012 Closed-Date: Last-Modified: Originator: Justin Release:9_0_RELENG-amd64 Organization: Environment: 9_0_RELENG_amd64 Description: My logitech PS/2 mouse doesn't get detected. verbose dmesg - http://paste.pocoo.org/show/532596 /boot/device.hints - http://paste.pocoo.org/show/532599 KERNCONF - http://paste.pocoo.org/show/532667/ I've tried using various parameters such as debug.acpi.disabled=hostres and some in /etc/X11/xorg.conf but it didn't work. On running moused -d -i all -p /dev/psm0 I get moused: unable to open /dev/psm0: No such file or directory The problem appears to be - atkbdc0: Keyboard controller (i8042) failed to probe at port 0x60 on isa0 Yes, that would be the root cause. Can you verbosely boot a kernel that doesn't have sound, many of the messages from the verbose dmesg above were lost. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/164036: Moused fails on 9_0_RELENG
The following reply was made to PR amd64/164036; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: dave shar freebsd.us...@gmail.com Cc: freebsd-amd64@freebsd.org, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/164036: Moused fails on 9_0_RELENG Date: Thu, 12 Jan 2012 14:45:00 -0500 On Thursday, January 12, 2012 9:44:22 am dave shar wrote: The problem appears to be - atkbdc0: Keyboard controller (i8042) failed to probe at port 0x60 on isa0 Yes, that would be the root cause. Can you verbosely boot a kernel that doesn't have sound, many of the messages from the verbose dmesg above were lost. -- John Baldwin Here is verbose boot without sound devices - http://paste.pocoo.org/show/533788/ Hmm, I dont' see atkbdc in there at all, however, I wonder if the fact that ACPI gives 0x60 to your PS/2 mouse device is what breaks this: psmcpnp0: PS/2 mouse port port 0x60,0x64 irq 12 on acpi0 Can you provide your acpidump -d output (note, it will be large)? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/162708: FreeBSD 9.0-RC2 amd64 fails to boot on Dell Optiplex GX620
The following reply was made to PR amd64/162708; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: David J. Weller-Fahy dave-freebsd-gn...@weller-fahy.com Cc: Peter Jeremy peterjer...@acm.org, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/162708: FreeBSD 9.0-RC2 amd64 fails to boot on Dell Optiplex GX620 Date: Thu, 29 Dec 2011 11:23:00 -0500 On Sunday, December 11, 2011 10:13:21 am David J. Weller-Fahy wrote: * John Baldwin j...@freebsd.org [2011-12-08 10:53 -0500]: Hmm, can you try this patch without the tunable: patch to sys/dev/acpica/acpi_pcib_acpi.c ... + res = bus_generic_alloc_resource(dev, child, type, rid, start, end, + count, flags); ... That worked! Specifically, I csup'd the source, patched the file, did a full buildworld/installworld cycle, then removed the tunable and was able to boot with no problems. Thanks! Do you need any information from this box as it stands? I've committed this. It is too late to make it for 9.0 but I will merge it to stable/9 once that opens up for commits again. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/163442: boot/loader.conf not processed at boot time
On Wednesday, December 21, 2011 12:55:27 pm Thomas D. Dean wrote: On Wed, 2011-12-21 at 07:43 -0500, John Baldwin wrote: On 12/20/11 1:06 PM, Thomas D. Dean wrote: Uh, so using grub to load the loader was the fix? That isn't a real fix. Can you disable the beastie (beastie_disable=YES) and the automatic boot (autoboot_delay=NO) in loader.conf and then either use a serial console or a camera to capture the messages on the screen when it loads the modules. Then do a boot -v from the prompt and save the output of 'dmesg' to a file after it boots. Put that file up somewhere where I can look at it to see if there were errors parsing the modules loaded from the loader. Sorry, I was not clear. I installed grub in my original configuration of the new machine, built from components, no OS. I created gpt partitions on two disks with linux. I installed windows 7 on the first disk, then, linux with grub on the second disk, fixing grub to boot windows. Then, I installed FreeBSD on the second disk. Again, I edited grub (in linux) to boot all three. At this point, I had grub configured to directly load the FreeBSD kernel, not using the loader. So, any loader configurations were not effective because the loader was never executed. The beastie never appeared. Until the discussion on this list, I never noticed the absence. This was a mistake on my part. I wanted to use the FreeBSD loader and get the benefits of configuring modules, etc., at boot time. Going back to linux and configuring grub properly to use the FreeBSD loader fixed the problem. I can try to gather information, but, I will have to go back to the improper (broken?) grub configuration to do it. Oh, nevermind, I understand now. No need for further information. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/163114: no boot on Via Nanao netbook Samsung NC20
On Wednesday, December 07, 2011 2:11:52 pm W.B.Kloke wrote: Number: 163114 Category: amd64 Synopsis: no boot on Via Nanao netbook Samsung NC20 Confidential: no Severity: serious Priority: medium Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Wed Dec 07 19:40:08 UTC 2011 Closed-Date: Last-Modified: Originator: W.B.Kloke Release:FreeBSD 9.0-RC3 i386 Organization: Environment: System: FreeBSD generic from 9.0-RC3-amd64-memstick.img Via Nano (CentaurHauls) on Samsung NC20 Description: does not bring up system without safe or no ACPI it hangs aufter pci0: ACPI PCI bus on pcib0 Can you do a verbose boot and see what the last message line it reports is? Would you also be able to capture a verbose boot log from 8.2? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/162708: FreeBSD 9.0-RC2 amd64 fails to boot on Dell Optiplex GX620
The following reply was made to PR amd64/162708; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: David J. Weller-Fahy dave-freebsd-gn...@weller-fahy.com Cc: Peter Jeremy peterjer...@acm.org, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/162708: FreeBSD 9.0-RC2 amd64 fails to boot on Dell Optiplex GX620 Date: Thu, 08 Dec 2011 10:48:37 -0500 On 12/3/11 10:11 PM, David J. Weller-Fahy wrote: * John Baldwinj...@freebsd.org [2011-11-29 15:30 -0500]: Try adding 'debug.acpi.disabled=hostres' at the loader prompt. Ah-hah - that worked! The delay was me testing that booting from CD, then upgrading my 8.2 w/ ZFS v28 system to 9.0-RC2 via freebsd-update, including debug.acpi.disabled=hostres in my `/boot/loader.conf`, and completing the update (including performing a complete reinstall of all ports using portmaster). Thanks for the help, and is there anything I need to try to see what needs to be fixed? Do you need information from this machine? I'm keeping the second hard-drive clear right now just in case I need to do some test installs. Well, it's more that your BIOS is providing inaccurate or incomplete information about what address ranges your Host-PCI bridges understand. That's not easily fixable (the tunable just ignores what the BIOS says). At some point what I may do is make the check more lenient so that always we trust requests for specific ranges. Hmm, can you try this patch without the tunable: Index: /home/jhb/work/freebsd/svn/head/sys/dev/acpica/acpi_pcib_acpi.c === --- /home/jhb/work/freebsd/svn/head/sys/dev/acpica/acpi_pcib_acpi.c (revision 228311) +++ /home/jhb/work/freebsd/svn/head/sys/dev/acpica/acpi_pcib_acpi.c (working copy) @@ -511,8 +511,16 @@ sc = device_get_softc(dev); res = pcib_host_res_alloc(sc-ap_host_res, child, type, rid, start, end, count, flags); +/* + * XXX: If this is a request for a specific range, assume it is + * correct and pass it up to the parent. What we probably want to + * do long-term is explicitly trust any firmware-configured + * resources during the initial bus scan on boot and then disable + * this after that. + */ if (res == NULL start + count - 1 == end) - res = acpi_alloc_sysres(child, type, rid, start, end, count, flags); + res = bus_generic_alloc_resource(dev, child, type, rid, start, end, + count, flags); return (res); #else return (bus_generic_alloc_resource(dev, child, type, rid, start, end, -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/162936: fails boot and destabilizes other OSes on FreeBSD 9 RC2 with MSI P6N SLI Platinum
The following reply was made to PR amd64/162936; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: freebsd-amd64@freebsd.org Cc: Kevin Ar18 kevina...@hotmail.com, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/162936: fails boot and destabilizes other OSes on FreeBSD 9 RC2 with MSI P6N SLI Platinum Date: Wed, 30 Nov 2011 08:20:14 -0500 On Monday, November 28, 2011 9:35:08 pm Kevin Ar18 wrote: Synopsis: fails boot and destabilizes other OSes on FreeBSD 9 RC2 with MSI P6N SLI Platinum ... Release:FreeBSD 9 RC2 Organization: Environment: * MSI P6N SLI Plantium (nForce 650i northbridge)(nForce 430i southbridge) * Intel Q6600 * USB Memory * 1x IDE drive * 1x SATA drive Description: Summary: Using the FreeBSD-8.2-RELEASE-amd64-memstick.img Hm, here you say 8.2, bit your title says 9? On a whim, if this is 9, can you try setting 'debug.acpi.disabled=hostres' from the loader prompt? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/162708: FreeBSD 9.0-RC2 amd64 fails to boot on Dell Optiplex GX620
The following reply was made to PR amd64/162708; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: David J. Weller-Fahy dave-freebsd-gn...@weller-fahy.com Cc: Peter Jeremy peterjer...@acm.org, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/162708: FreeBSD 9.0-RC2 amd64 fails to boot on Dell Optiplex GX620 Date: Tue, 29 Nov 2011 15:26:17 -0500 On Friday, November 25, 2011 12:16:30 am David J. Weller-Fahy wrote: * David J. Weller-Fahy dave-freebsd-gn...@weller-fahy.com [2011-11-24 14:41 -0500]: When doing the upgrade, I noticed /boot/device.hints had an addition for attimer.0. I'll next try to get 9.0-RC2 to boot without ACPI (I'll try removing that hint). Removed the hints regarding attimer.0, same results. Try adding 'debug.acpi.disabled=hostres' at the loader prompt. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/162708: FreeBSD 9.0-RC2 amd64 fails to boot on Dell Optiplex GX620
The following reply was made to PR amd64/162708; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: freebsd-amd64@freebsd.org Cc: David J. Weller-Fahy dave-freebsd-gn...@weller-fahy.com, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/162708: FreeBSD 9.0-RC2 amd64 fails to boot on Dell Optiplex GX620 Date: Tue, 22 Nov 2011 08:17:04 -0500 On Sunday, November 20, 2011 6:57:40 pm David J. Weller-Fahy wrote: When enabled the machine freezes with the following messages being the last before the freeze (this is after pressing enter at the CD's boot prompt). #v+ .. hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 Event timer HPET frequency 14318180 Hz quality 450 Event timer HPET1 frequency 14318180 Hz quality 440 Event timer HPET2 frequency 14318180 Hz quality 440 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 #v- In verbose mode it freezes with the last messages as follows. #v+ .. pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 21 pcib0: allocated type 3 (0xdf70-0xdf7003ff) for rid 10 of pci0:0:29:7 unknown: Lazy allocation of 0x400 bytes rid 0x10 type 3 at 0xdf70 #v- Can you get a verbose dmesg from a boot of 8.2? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/162361: Will the InTel Core 2 Duo 6320 work with FreeBSD
The following reply was made to PR amd64/162361; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: freebsd-amd64@freebsd.org Cc: ROY MCKINLEY roy_...@yahoo.com, freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/162361: Will the InTel Core 2 Duo 6320 work with FreeBSD Date: Tue, 8 Nov 2011 07:50:30 -0500 On Monday, November 07, 2011 5:22:14 pm ROY MCKINLEY wrote: Number: 162361 Category: amd64 Synopsis: Will the InTel Core 2 Duo 6320 work with FreeBSD Confidential: no Severity: non-critical Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Mon Nov 07 22:30:09 UTC 2011 Closed-Date: Last-Modified: Originator: ROY MCKINLEY Release:7.2 Organization: @home Environment: InTel Core 2 Duo 6320 Description: Will FreeBSD 7.2 install on the InTel Core 2? How-To-Repeat: FreeBSD should support that CPU just fine and should probably support most of the peripherals on a typical Core 2 Duo motherboard, but for a more accurate answer about a specific machine you would need to ask about support for a specific machine (i.e. what devices are used such as LAN controller, etc.). Also, this sort of topic is best covered on questi...@freebsd.org, not in a PR. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: 32-bit binaries (e.g. wine) and 64-bit kernel structures
On Sunday, October 23, 2011 7:04:51 pm Li-Lun Leland Wang wrote: Hi, Although I only encounter this kind of problem when running wine (because it is one of the few ports that need to compile into 32-bit), it is a problem of i386 binaries on x64 FreeBSD in general. The problem that I'm running into recently is http://bugs.winehq.org/show_bug.cgi?id=28857 . In short, wine recently implemented GetUdpTable() for Mac OS and BSD. It uses sysctlbyname() to get net.inet.udp.pcblist, and parses it into xinpgen structures. However, the size of xinpgen is different on i386 and x64. As a result, when I run applications that call GetUdpTable(), the kernel supplies wine with 64-bit structures, while wine expects 32-bit structures, and crashes. They decided that this is a FreeBSD bug rather than a wine bug, and that the kernel or LD should know a 32-bit binary is being run and return proper structures, as is done in Mac OS. xinpgen is not the only structure of wrong sizes for 32-bit binaries on x64. A while ago I was trying to make my usb gamepad work on wine using the ugen device. libusbhid uses ioctl to get the usb_gen_descriptor structure, which is also of different sizes on i386 and x64. I had to manually pad the pointers to 64-bit and build a custom libusbhid for it to work. As it stands, they will probably not fix GetUdpTable() on wine side, and any windows applications that uses GetUdpTable() will not run properly in wine on FreeBSD x64. Do we have plans to fix this kind of problems in general? Although wine port on FreeBSD is only supported for ARCH=i386, could there be workarounds? Fixing this problem generically is very hard. Instead, we have patched individual sysctls and ioctls on a case-by-case basis. I do think newer interfaces often opt to use fixed-size types so that the structure is the same for both 32-bit and 64-bit, but that will not work for existing interfaces. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/161493: NFS v3 directory structure update slow
19963641 0 How-To-Repeat: imap5# mkdir test1 imap5# cd test1 imap5# touch file1 imap5# touch file2 imap5# ls -la ls: ..: Input/output error total 4 drwxr-xr-x 2 root vchkpw 512 Oct 11 10:55 . -rw-r--r-- 1 root vchkpw0 Oct 11 10:55 file1 -rw-r--r-- 1 root vchkpw0 Oct 11 10:55 file2 Fix: Can you try using the old NFS server as a test? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/161493: NFS v3 directory structure update slow
The following reply was made to PR amd64/161493; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: freebsd-amd64@freebsd.org Cc: George Breahna geo...@polarismail.com, freebsd-gnats-sub...@freebsd.org, Rick Macklem rmack...@freebsd.org Subject: Re: amd64/161493: NFS v3 directory structure update slow Date: Wed, 12 Oct 2011 09:29:39 -0400 On Tuesday, October 11, 2011 11:07:13 am George Breahna wrote: Number: 161493 Category: amd64 Synopsis: NFS v3 directory structure update slow Confidential: no Severity: critical Priority: high Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Tue Oct 11 15:10:07 UTC 2011 Closed-Date: Last-Modified: Originator: George Breahna Release:9.0 Beta 2 Organization: Environment: FreeBSD store2 9.0-BETA2 FreeBSD 9.0-BETA2 #0: Sun Sep 18 22:02:45 EDT 2011 pul...@store2.emailarray.com:/usr/obj/usr/src/sys/PULSAR amd64 Description: We used to run a NFS server on FreeBSD 6.2 but we built a new box recently and installed 9.0 Beta 2 on it. The data was moved over as it serves as the back-end for a mail system. It runs NFS v3 over TCP only and all the NFS- related processes (rpcbind, mountd, lockd, etc ) run with the -h switch and bind to the local IP address. The NFS server exports the data to 7 NFS clients ranging from FreeBSD 6.1 to 8.2, the majority being 8.2 The mount on the NFS clients is done simply with - o tcp,rsize=32768,wsize=32768 Usual file operations, such as accessing files, creating directories, removing files, chmod, chown, etc work perfectly but we noticed there were issues in removing directories that contained data. We had a strange error: rm -rf nick/ rm: fts_read: Input/output error Using 'truss' on rm revealed this: open(..,O_RDONLY,00) ERR#5 'Input/output error' After much testing and debugging we realized the problem is in the NFS protocol. ( either server or client but we assume server since this used to work very well with FreeBSD 6.2 ). The problem appears to be that NFS does not show the '..' after modifying a directory structure. Take the following example executed on a FreeBSD 8.2 client accessing the NFS share from the 9.0B2 server: imap5# mkdir test1 imap5# cd test1 imap5# touch file1 imap5# touch file2 imap5# ls -la ls: ..: Input/output error total 4 drwxr-xr-x 2 root vchkpw 512 Oct 11 10:55 . -rw-r--r-- 1 root vchkpw0 Oct 11 10:55 file1 -rw-r--r-- 1 root vchkpw0 Oct 11 10:55 file2 Notice the '..' is missing from the display. If we now try and remove the directory 'test1' it will throw the rm: fts_read: Input/output error error. If we wait in between 1 minute and 5 minutes, '..' will eventually appear by itself. During this whole time, '..' effectively exists on the NFS server but it's not displayed by any of the NFS clients. I can force the NFS client to show it faster by doing an ls -la from the parent level. For example: imap5# mkdir test1 imap5# touch test1/file1 imap5# touch test1/file2 imap5# touch test1/file3 imap5# ls -la test1 total 8 drwxr-xr-x 2 root vchkpw 512 Oct 11 10:59 . drwx-- 10 vpopmail vchkpw 1024 Oct 11 10:59 .. -rw-r--r-- 1 root vchkpw 0 Oct 11 10:59 file1 -rw-r--r-- 1 root vchkpw 0 Oct 11 10:59 file2 -rw-r--r-- 1 root vchkpw 0 Oct 11 10:59 file3 imap5# cd test1 imap5# ls -la total 8 drwxr-xr-x 2 root vchkpw 512 Oct 11 10:59 . drwx-- 10 vpopmail vchkpw 1024 Oct 11 10:59 .. -rw-r--r-- 1 root vchkpw 0 Oct 11 10:59 file1 -rw-r--r-- 1 root vchkpw 0 Oct 11 10:59 file2 -rw-r--r-- 1 root vchkpw 0 Oct 11 10:59 file3 but if we wait 5 seconds after that display and try again: ls -la ls: ..: Input/output error total 4 drwxr-xr-x 2 root vchkpw 512 Oct 11 10:59 . -rw-r--r-- 1 root vchkpw0 Oct 11 10:59 file1 -rw-r--r-- 1 root vchkpw0 Oct 11 10:59 file2 -rw-r--r-- 1 root vchkpw0 Oct 11 10:59 file3 Again, if we wait longer ( 1-5 minutes ), the '..' will properly appear in there. There are no error messages on the console or other log files. This is reproducible 100% of the time with any FreeBSD client. Have tried unmounting/remounting several times without any effect. Also tried different rsize/wsize, no effect. I think there is some delay in updating the directory structure and it's causing this bug. Here's also some output from nfsstat on the server: Server Info: Getattr SetattrLookup Readlink Read WriteCreate Remove 114731225 20496896 254966151 133 11697392 19963641 0 9228861 Rename Link
Re: amd64/160801: zfsboot on 8.2-RELEASE fails to boot from root-on-zfs in MBR slice
On Sunday, September 18, 2011 9:01:11 am Camillo SXrs wrote: Number: 160801 Category: amd64 Synopsis: zfsboot on 8.2-RELEASE fails to boot from root-on-zfs in MBR slice Confidential: no Severity: serious Priority: low Responsible:freebsd-amd64 State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Sun Sep 18 13:10:07 UTC 2011 Closed-Date: Last-Modified: Originator: Camillo Särs Release:8.2-RELEASE Organization: Environment: FreeBSD free 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Description: /boot/zfsboot when installed fails to boot from root-on-zfs in MBR slice, set up according to this: http://wiki.freebsd.org/RootOnZFS/ZFSBootPartition I upgraded from 8.1 to 8.2-RELEASE, and consequently upgraded my zfs root pool to version 15. Upgraded the bootloader in Fixit prompt to allow booting from v15 pool. After this, the system fails to boot, and freezes after the Boot: F1 prompt with - on the screen. See this thread for example screenshot: http://forums.freebsd.org/showthread.php?t=22105 MBR is used because of BIOS incompatibility with GPT as installed by FreeBSD. How-To-Repeat: Set up root-on-ZFS in MBR slice on 8.2-RELEASE according to: http://wiki.freebsd.org/RootOnZFS/ZFSBootPartition Reboot - system halts on -. Fix: Install zfsboot from 9.0-BETA2, where the problem is fixed. Can you test 8.2-stable? The various fixes made to zfsboot in 9 were merged to 8 after 8.2-release. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/159930: kernel core
On Friday, August 19, 2011 6:50:51 pm Wouter Snels wrote:
Number: 159930
Category: amd64
Synopsis: kernel core
Confidential: no
Severity: non-critical
Priority: medium
Responsible:freebsd-amd64
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Fri Aug 19 23:00:25 UTC 2011
Closed-Date:
Last-Modified:
Originator: Wouter Snels
Release:FreeBSD 8.2
Organization:
Environment:
FreeBSD spark.ofloo.net 8.2-RELEASE-p2 FreeBSD 8.2-RELEASE-p2 #0: Wed Jul 13
15:20:57 CEST 2011 of...@spark.ofloo.net:/usr/obj/usr/src/sys/OFL amd64
Description:
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address = 0x30
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x805dd943
stack pointer = 0x28:0xff8091e3d6c0
frame pointer = 0x28:0xff8091e3d6f0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 18 (softdepflush)
trap number = 12
panic: page fault
cpuid = 2
KDB: stack backtrace:
#0 0x8063300e at kdb_backtrace+0x5e
#1 0x80602627 at panic+0x187
#2 0x808fbbe0 at trap_fatal+0x290
#3 0x808fbfbf at trap_pfault+0x28f
#4 0x808fc49f at trap+0x3df
#5 0x808e4644 at calltrap+0x8
#6 0x805f668a at priv_check_cred+0x3a
#7 0x8084ebd0 at chkdq+0x310
#8 0x8082db5d at ffs_truncate+0xfed
#9 0x8084ac5c at ufs_inactive+0x21c
#10 0x8068a761 at vinactive+0x71
#11 0x806904b8 at vputx+0x2d8
#12 0x80836386 at handle_workitem_remove+0x206
#13 0x8083675e at process_worklist_item+0x20e
#14 0x80838893 at softdep_process_worklist+0xe3
#15 0x80839d3c at softdep_flush+0x17c
#16 0x805d9f28 at fork_exit+0x118
#17 0x808e4b0e at fork_trampoline+0xe
Uptime: 2d4h7m56s
Cannot dump. Device not defined or unavailable.
Automatic reboot in 15 seconds - press a key on the console to abort
panic: bufwrite: buffer is not busy???
Hmm, the panic seems to be caused by a null ucred pointer passed to
priv_check_cred() in chkdq():
if ((flags FORCE) == 0
priv_check_cred(cred, PRIV_VFS_EXCEEDQUOTA, 0))
do_check = 1;
else
do_check = 0;
However, ffs_truncate() passes in NOCRED for its credential:
if ((flags IO_EXT) extblocks 0) {
...
#ifdef QUOTA
(void) chkdq(ip, -extblocks, NOCRED, 0);
#endif
A few other places call chkdq() with NOCRED (but not with the FORCE flag):
ffs/ffs_inode.c:522:(void) chkdq(ip, -blocksreleased, NOCRED, 0);
ffs/ffs_softdep.c:6201: (void) chkdq(ip, -datablocks, NOCRED, 0);
ffs/ffs_softdep.c:6431: (void) chkdq(ip, -datablocks, NOCRED, 0);
Hmm, all these calls should be passing in a negative value though, and
reducing usage takes a shorter path at the start of chkdq() that always
returns without ever getting to the call to priv_check_cred(). Similarly if
the value (e.g. extblocks) was 0. This implies that extblocks was a negative
value which seems very odd. Especially given the logic in ffs_truncate():
if ((flags IO_EXT) extblocks 0) {
...
if ((error = ffs_syncvnode(vp, MNT_WAIT)) != 0)
return (error);
#ifdef QUOTA
(void) chkdq(ip, -extblocks, NOCRED, 0);
#endif
Nothing changes extblocks in between that check and the call to chkdq(). It
would probably be best to get a crashdump if this is reproducible so we can
investigate it further.
--
John Baldwin
___
freebsd-amd64@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
); } /* @@ -627,7 +644,7 @@ freq = i8254_freq; error = sysctl_handle_int(oidp, freq, 0, req); if (error == 0 req-newptr != NULL) - set_i8254_freq(freq, hz); + set_i8254_freq(freq, hz, 0); return (error); } Index: amd64/include/clock.h === --- amd64/include/clock.h (.../mirror/FreeBSD/stable/8/sys) (revision 224114) +++ amd64/include/clock.h (.../stable/8/sys) (revision 224114) @@ -32,10 +70,11 @@ /* * Driver to clock driver interface. */ void startrtclock(void); void init_TSC(void); void init_TSC_tc(void); +void DELAY_TSCCAL(int n); #defineHAS_TIMER_SPKR 1 inttimer_spkr_acquire(void); Index: amd64/amd64/tsc.c === --- amd64/amd64/tsc.c (.../mirror/FreeBSD/stable/8/sys) (revision 224114) +++ amd64/amd64/tsc.c (.../stable/8/sys) (revision 224114) @@ -87,7 +92,7 @@ printf(Calibrating TSC clock ... ); tscval[0] = rdtsc(); - DELAY(100); + DELAY_TSCCAL(100); tscval[1] = rdtsc(); tsc_freq = tscval[1] - tscval[0]; -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: powernow regression in 8-STABLE
On Wednesday, July 20, 2011 10:28:19 pm Callum Gibson wrote: On 20Jul11 19:28, Jung-uk Kim wrote: }From your dmesg output, I see that the processor speed was not }calibrated properly. ML-40's max. core freq. is 2,200 MHz according }to its specification but it was probed at 2,282 MHz, which is too }high. I think that's the problem. Can you please try the attached }patch? Yes, I have seen core freq wobble around for most of the time I've owned it, but usually close to 2200. Possibly try disabling legacy USB in your BIOS as a test? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: Understanding i386 PAE
On Monday, May 09, 2011 12:31:48 pm Brad Waite wrote: Hi all, I've got some questions about i386 PAE. I was pointed towards this list, but if another is more appropriate, just let me know. I also know that i386 PAE is the ugly, red-headed step-child of FreeBSD. Kindly keep the standard why don't you use amd64 statements to a minimum. My aim is to gain an accurate understanding of how things work with my antiquated and lowly 32-bit hardware. Based on my research, hardware w/PAE support can address up to 64G of memory via a 36-bit addressing scheme. However, since an i386 process can only address 32 bits, each process gets at most 4G of that 64G. In my case, my Intel SE7501BR2, dual 2GHz Xeon server supports 8G max and I want to use 6G, maximizing the kernel memory. I understand that KVA_PAGES determines the amount of memory reserved for the kernel, and therefore userland processes. But where does the kernel fit into that 32-bit/4G limit? My original understanding was that the kernel was a process, just like userland ones, and could address 4G and therefore I could split my 6G into 4G for the kernel and 2G for userland (KVA_PAGES = 2048). I've been informed that PAE doesn't actually work that way. Instead, the kernel-reserved memory is per-process and setting KVA_PAGES to 2048 means the kernel takes up all of the 4G of a process' addressable memory, which obviously won't work. Is the latter actually the case or is my original understanding correct? Or is it somewhere in between? FreeBSD uses a shared address space on x86 (both i386 and amd64) where the kernel is mapped into every process' address space at a fixed address. This makes it cheaper and easier to copy data between a user process and the kernel since you don't have to temporarily map user pages into the kernel's address space, etc. It is possible to use separate address spaces for the kernel and userland (other OS's have done this) so that you could have 4G for the kernel and 4G for userland. However, this would require a good bit of work in the kernel (e.g. copyin/copyout would have to start mapping user pages at temporary addresses in the kernel). As you have noted, PAE does not increas your virtual address space, merely your phyiscal address space by changing PTEs to use 64-bit physical addresses instead of 32-bit physical addresses. However, each process can only address up to 4G of RAM at a time. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/156014: FreeBSD 8.2-RELEASE amd64 freeze and crash
On Thursday, April 07, 2011 07:20:11 pm Rodrigo OSORIO wrote: The following reply was made to PR amd64/156014; it has been noted by GNATS. From: Rodrigo OSORIO rodr...@bebik.net To: bug-follo...@freebsd.org, rodr...@bebik.net Cc: Subject: Re: amd64/156014: FreeBSD 8.2-RELEASE amd64 freeze and crash Date: Fri, 08 Apr 2011 01:12:55 +0200 Hi, After reinstall the full system in 8.2-RELEASE, the crashes persist You can find the full crash dump here : http://www.bebik.net/~rodrigo/freebsd/NewCrash/ Can you fire up kgdb and do 'proc 2' followed by 'bt' and reply with the output? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/117186: [modules] kldload Unsupported file type on STABLE amd64
On Wednesday, March 02, 2011 6:00:22 am Agarwal, Mayank wrote: The following reply was made to PR amd64/117186; it has been noted by GNATS. From: Agarwal, Mayank mayank.agar...@netapp.com To: bug-follo...@freebsd.org, s...@mcneil.com Cc: Subject: Re: amd64/117186: [modules] kldload Unsupported file type on STABLE amd64 Date: Wed, 2 Mar 2011 15:54:00 +0530 This is a multi-part message in MIME format. --_=_NextPart_001_01CBD8C3.F2859328 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi,=20 =20 I am running a FreeBSD 7.2 amd64 machine. While I am trying to load a=20 kernel module I got following error:=20 =20 kldload: ./modules/base_kmod.ko: Unsupported file type=20 After this error kernel panicked with following message:=20 There should have been another message on the console before the panic that would explain why you got the error from kldload. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/141413: [hang] Tyan 2881 m3289 SMDC freeze
On Wednesday, February 02, 2011 11:50:12 pm Robert Clemens wrote: The following reply was made to PR amd64/141413; it has been noted by GNATS. From: Robert Clemens rob...@solidsolutions.net To: bug-follo...@freebsd.org, bkyoung7...@yahoo.com, a...@freebsd.org Cc: Subject: Re: amd64/141413: [hang] Tyan 2881 m3289 SMDC freeze Date: Wed, 02 Feb 2011 22:42:42 -0600 I apologize for the length of this followup but wanted to detail this as much as possible for future readers and what I believe to be the closing of PR141413 now that it appears to be resolved. With the documentation I have provided I feel this is easily duplicated. I pulled out the old trusty dev box (exact specs listed for this PR). Tyan s2881 motherboard with m3289 SMDC card. FreeBSD 8.2-RC2 works great with remote ipmi management while power is off, during bootup, and during normal operational init multiuser conditions. I last tried this for FreeBSD 8.1-RELEASE. I can't speak for when this started working but it was after 8.1-REL and sometime during 8.2-RCx. One thing I did notice is I no longer see ipmi0 dev or ipmi information from dmesg as I used to. I'm not exactly sure the intended functionality of the ipmi0 disappearance. This results in the inability to use ipmitool to connect locally from the machine in question as was once possible -- actually this was the only way previous to use the ipmi functionality before 8.2-RCx. That may still result in an open issue but as far as I'm concerned, I'm quite ecstatic to see a working console login via com2 over lan. Can you get the ipmi lines from an older dmesg when it worked? The output of dmidecode may also be useful. // i also needed to bind the ip for the smdc to my network interface. // i used 192.168.1.199 on the smdc firmware. i added this as an alias to my network interface. // notice i am using lagg0 but you would likely just be using bge0 // the only thing below of concern is that you can indeed see that 192.168.1.199 is active on my (pseudo-)NIC. That is very odd. In general with a BMC, the packets never make it to the OS, so you shouldn't need to do this. Perhaps the BMC is not responding to ARP so by putting the IP in the host OS you cause the host OS to respond to ARP requests but the BMC then sniffs the IP traffic? Can you verify that this step is required for you, and if so can you run a tcpdump of ARP packets on bge0 while doing a remote ipmitool command to see if you see ARP requests for the BMC IP in the host OS? Let me know if I missed something or need to clarify. It's hard to have amazing formatting in an email so it is a little sloppy. The general issue from the PR sounds very much like a problem with bge(4) and not specific to the IPMI or amd64 support. We use IPMI with igb(4) parts at work without any issues, and we do not add the BMC IP as an alias on our igb interfaces. -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/141413: [hang] Tyan 2881 m3289 SMDC freeze
On Thursday, February 03, 2011 10:43:00 am Robert Clemens wrote: On Thu, Feb 3, 2011 at 6:42 AM, John Baldwin j...@freebsd.org wrote: Can you get the ipmi lines from an older dmesg when it worked? The output of dmidecode may also be useful. This is from another server I have running. FreeBSD abyss.solidsolutions.net 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 [root@abyss /var/run]# cat dmesg.boot |grep ipmi ipmi0: IPMI System Interface on isa0 ipmi0: KCS mode found at io 0xca2 alignment 0x1 on isa ipmi0: IPMI device rev. 1, firmware rev. 1.81, version 1.5 ipmi0: Number of channels 1 ipmi0: Attached watchdog [root@abyss /var/run]# Handle 0x003B, DMI type 38, 16 bytes IPMI Device Information Interface Type: KCS (Keyboard Control Style) Specification Version: 1.5 I2C Slave Address: 0x10 NV Storage Device: Not Present Base Address: 0x0CA2 (I/O) Does the server running 8.2 have identical dmidecode output? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
