Re: CVS commit: src/sys/dev/acpi
On Mon, Jul 19, 2010 at 09:32:58AM +0300, Jukka Ruohonen wrote: This is a known issue. No clean solution exist in any implementation I am aware of. The IDs may also vary between the processor object and MADT. As I noted to Christos in private mail, the right solution is likely to include the ACPI processor object ID in (x86) cpu_info and operate with that value only. The specification imposes no restrictions on these IDs; some BIOSes may start counting the ACPI CPUs from zero and others from one. Due to the reasons with the identification, I think we might want to attach them all nevertheless. I also checked the ACPI tables of some servers; these may define even up to 0xFF processor objects by default, possibly in order to use the same tables with different models, etc. Another case is virtualized environments. So, yes, we should only attach those ACPI CPUs that have a real counterpart. - Jukka.
Re: CVS commit: src/sys/dev/acpi
Module Name: src Committed By: christos Date: Mon Jul 19 00:59:32 UTC 2010 Modified Files: src/sys/dev/acpi: acpi_cpu.c acpi_cpu.h acpi_cpu_cstate.c Log Message: XXX: If this is not correct, revert or fix. This makes my laptop boot instead of panic: panic: kernel diagnostic assertion native_idle != NULL failed: file ../../../../arch/x86/acpi/acpi_cpu_md.c, line 155 fatal breakpoint trap in supervisor mode type 1 code 0 rip 8022e4ad cs 8 rflags 246 cr2 0 cpl 0 rsp 80004c37db10 trace breakpoint() at netbsd:breakpoint+0x5 panic() at netbsd:panic+0x2ba kern_assert() at netbsd:kern_assert+0x2d acpicpu_md_idle_stop() at netbsd:acpicpu_md_idle_stop+0x62 acpicpu_cstate_callback() at netbsd:acpicpu_cstate_callback+0x34 sysmon_task_queue_thread() at netbsd:sysmon_task_queue_thread+0x41 1. ACPI seems to define cpuids 1..n; we define 0..n-1. Adjust for that No, ACPI enumerates cpus 0..n-1 by specification. 2. My laptop is dual core, but ACPI reports 4 cpu nodes. Instead of attaching the unmatched ones, make the match fail. Do we want to attach and do nothing instead? Uh, do your two cores attach on id 1 and 2 and ids 0 and 3 are unused? That sounds like your laptop vendor prepared the BIOS to deliver laptop models with a quad-core cpu. 3. Create a flag, and only set it after we are completely initialized, so the sysmon thread does not try to access unitialized state.
Re: CVS commit: src/sys/dev/acpi
On Mon, Jul 19, 2010 at 09:32:58AM +0300, Jukka Ruohonen wrote: On Sun, Jul 18, 2010 at 08:59:33PM -0400, Christos Zoulas wrote: 1. ACPI seems to define cpuids 1..n; we define 0..n-1. Adjust for that ACPI is silent about the CPU IDs in the processor object. In all three Huh? 8.4 Declaring Processors [...] When the platform uses the APIC interrupt model, OSPM associates processors declared in the namespace with entries in the MADT. Prior to ACPI 3.0, this was accomplished using the processor object's ProcessorID and the ACPI Processor ID fields in MADT entries. UID fields were added to MADT entries in ACPI 3.0. By expanding processor declaration using Device definitions, UID object values under a processor device are used to associate processor devices with entries in the MADT. This removes the previous 256 processor declaration limit. -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling KT Tunstall, Saving My Face, Drastic Fantastic, 2007. pgpiWiBqs23aC.pgp Description: PGP signature
re: CVS commit: src/distrib/sets/lists/xcomp
Module Name: src Committed By: njoly Date: Mon Jul 19 14:30:51 UTC 2010 Modified Files: src/distrib/sets/lists/xcomp: shl.mi Log Message: Add libxcb-*.debug files. thanks. .mrg.
re: CVS commit: src/sys/netinet
Module Name: src Committed By: rmind Date: Mon Jul 19 14:09:45 UTC 2010 Modified Files: src/sys/netinet: in_var.h ip_input.c ip_reass.c ip_var.h Log Message: Abstract IP reassembly into single generic routine - ip_reass_packet(). Make struct ipq private and struct ipqent not visible to userland. Push ip_len adjustment into reassembly layer. OK matt@ my build is now failing with: In file included from /usr/src/libexec/identd/identd.c:22: /var/obj/i386/usr/src/destdir.i386/usr/include/netinet/tcp_var.h:187: error: field 'segq' has incomplete type /var/obj/i386/usr/src/destdir.i386/usr/include/netinet/tcp_var.h:300: error: field 'timeq' has incomplete type please fix this or back out your changes. this is the 2nd time recently you have broken the build by not running a full build when changing header files. always run a full build when you are making changes like this - that's the rule. .mrg.