Date: Tue, 05 Aug 2014 16:25:54 -0400 From: Michael Butler <imb@protected-networks.net> To: John Baldwin <jhb@FreeBSD.org>, David Wolfskill <david@catwhisker.org> Cc: current@freebsd.org Subject: Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515] Message-ID: <53E13DD2.2020109@protected-networks.net> In-Reply-To: <C248C4AE-65AB-406A-A523-F7D7FAA8FBBE@FreeBSD.org> References: <20140804194759.GT1228@albert.catwhisker.org> <20140805142914.GJ1228@albert.catwhisker.org> <C248C4AE-65AB-406A-A523-F7D7FAA8FBBE@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/05/14 16:02, John Baldwin wrote: >> Given that my build machine did not exhibit the symptoms, and given the >> references to atpic, it may be relevant to point out that the machine >> where I see the panic is a Dell Precision M4400 laptop. > > My guess is that the recent Xen changes tickled something. However, can you capture a verbose dmesg from your working kernel? I have the same (or similar) symptom on an old core-duo Toshiba. It seems to occur just before hwpmc would normally show in the log: kernel: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 kernel: ada0: <Hitachi HTS725050A9A364 PC4OC70E> ATA-8 SATA 2.x device kernel: ada0: Serial Number 101105PCK404VLKU1WXJ kernel: ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) kernel: uhub2: 2 ports with 2 removable, self powered kernel: uhub3: 2 ports with 2 removable, self powered kernel: ada0: Command Queueing enabled kernel: ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) kernel: ada0: Previously was known as ad4 kernel: SMP: AP CPU #1 Launched! ** non working kernel panics here ** kernel: hwpmc: SOFT/16/64/0x67<INT,USR,SYS,REA,WRI> TSC/1/64/0x20<REA> IAP/2/40/0x3ff<INT,USR,SYS,EDG,THR,REA,WRI,INV,QUA,PRC> kernel: Timecounter "TSC" frequency 1662542340 Hz quality 1000 kernel: Root mount waiting for: usbus4 On another machine, which has 4 drives in two geom mirrors, it refuses to find ada0 or ada1. It reports a CAM timeout on the ATA-IDENTIFY phase with an apparently non-functioning interrupt problem. Reverting to a kernel built on July 27th restores normal behaviour, imb
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53E13DD2.2020109>