similar to: ASUS P4BGL-MX hangs

I'm trying to get stable booted on a little ITX board off of a CF card, but it hangs as it's trying to run init. Here's what the boot looks like. SMAP type=01 base=0000000000000000 len=000000000009fc00 SMAP type=01 base=000000000009fc00 len=0000000000000400 SMAP type=02 base=00000000000f0000 len=0000000000010000 SMAP type=02 base=00000000ffff0000 len=0000000000010000 SMAP type=01

Hello, I have the following hardware configuration. Tyan 2466N motherboard, 1.03 BIOS, 2 Athlon-MP 1800+ CPUs, 512MB registered ECC DRAM, Onboard 3Com NIC (xl type) Radeon 8500 AGP video card Adaptec 3210S SCSI RAID controller Comtrol RocketPort 8 port PCI serial card I have started to experience some odd system lockups in the past couple months, and it seems to be getting worse. I particular,

Good morning, I'm having a bit of an issue getting a 3CR990B-TXM NIC detected and usable. Just wondering if anyone knows of any issues with this NIC chipset and/or with the motherboard chipset. The motherboard is a Biostar GeForce 6100 AM2 using an nVidia nForce 410 chipset and nVidia GeForce 6100 vide chipset. I've tried FreeBSD 6.1, 6.2, 6-STABLE (from Wed), and 7-CURRENT (from

Hi all, Trying to upgrade a system from 9.0-RELEASE to 9.1-PRE from yesterday on my machine (GEOM+ZFS mirror setup on ada[01]p3), the new kernel becomes unable to mount root... The only way to recover is to boot from 9.0 kernel. The disks were already named ada[01] in 9.0, so I suspect nothing there... I tried - disabling AHCI in bios (no change seen) - change cables, check PSU, test disks

Hi, We're having some trouble with detection of a couple of Sil3124 SATA controller cards on newer motherboard and processor combos. Specifically, we're running a Supermicro X9SCM-F motherboard (latest BIOS) and Intel E3-1220v2 CPU. What we're seeing: - Syba Sil3124 PCIe cards are only being detected when installed in PCIe Slot 4 -- The motherboard documentation shows that this

Well this is new. I haven't a clue what Dell has done on this R620, but this popped up today after I did a boat load of BIOS updates and tried to install stable/9 from our yahoo tree. If anyone sees the obvious solution here, I'd love to figure it out. found-> vendor=0x14e4, dev=0x165f, revid=0x00 domain=0, bus=2, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1

hi folks: xorg caused my macbook 10,1 reboot immediately while startup X with latested nvidia-driver and event not to generate Xorg.0.log file attached my verbose message. thanks for any ideas --wsk -------------- next part -------------- Sep 20 15:40:31 rmbp syslogd: kernel boot file is /boot/kernel/kernel Sep 20 15:40:31 rmbp kernel: 2 Sep 20 15:40:31 rmbp kernel: MADT: Interrupt override:

Thomas, Have spoken to Soren, from my bootlog he believes that the problem is in atapicam causing the system to lock up. He is happy to answer some questions but doesnt have time to delve into atapicam himself. Did you author atapicam, I have seen your name on the sourcecode, can you help me further? Whats next? Thanks Adam. -------------- next part -------------- An embedded message was

Hi, there's a regression going from 6.2 to 6.3, where it will panic upon booting the kernel within vm_fault. This problem has been discussed before, but I'm seeing it reliably on a RELENG_6 checkout from 5th of May. It affects multiple (but identical) systems, here's an verbose boot leading to the panic. Please note that 6.2 was running fine on these machines, they also boot

I'm seeing oopses in probe_roms() and pci_find_bios(), apparently because those pages are not mapped under Xen. I'm not sure why I'm seeing this now and not before, but I suspect its because I enabled CONFIG_DEBUG_PAGEALLOC. Anyway, I've got these patches to deal with these cases: --- a/arch/i386/kernel/setup.c +++ b/arch/i386/kernel/setup.c @@ -276,7 +276,14 @@ static

I'm seeing oopses in probe_roms() and pci_find_bios(), apparently because those pages are not mapped under Xen. I'm not sure why I'm seeing this now and not before, but I suspect its because I enabled CONFIG_DEBUG_PAGEALLOC. Anyway, I've got these patches to deal with these cases: --- a/arch/i386/kernel/setup.c +++ b/arch/i386/kernel/setup.c @@ -276,7 +276,14 @@ static

In include/sys/pci.h we have #define MAX_PCI_BUSES 255 and struct pci_bus_list { struct pci_bus pci_bus[MAX_PCI_BUSES]; uint8_t count; }; And in lib/pci/scan.c for (bus = 0; bus <= MAX_PCI_BUSES; bus++) { pci_bus_list->pci_bus[bus].pci_device_count = 0; Fix possible overflows and introduce MAX_PCI_FUNC. - Sebastian Index: syslinux-20080611/com32/lib/pci/scan.c

On Mon, Jan 07, 2019 at 11:53:41AM +0800, Jason Wang wrote: > > On 2019/1/7 ??11:28, Michael S. Tsirkin wrote: > > On Mon, Jan 07, 2019 at 10:19:03AM +0800, Jason Wang wrote: > > > On 2019/1/3 ??4:47, Michael S. Tsirkin wrote: > > > > On Sat, Dec 29, 2018 at 08:46:51PM +0800, Jason Wang wrote: > > > > > This series tries to access virtqueue metadata

On 2018/12/26 ??11:02, Michael S. Tsirkin wrote: > On Wed, Dec 26, 2018 at 11:57:32AM +0800, Jason Wang wrote: >> On 2018/12/25 ??8:50, Michael S. Tsirkin wrote: >>> On Tue, Dec 25, 2018 at 06:05:25PM +0800, Jason Wang wrote: >>>> On 2018/12/25 ??2:10, Michael S. Tsirkin wrote: >>>>> On Mon, Dec 24, 2018 at 03:53:16PM +0800, Jason Wang wrote:

On 2018/12/25 ??8:50, Michael S. Tsirkin wrote: > On Tue, Dec 25, 2018 at 06:05:25PM +0800, Jason Wang wrote: >> On 2018/12/25 ??2:10, Michael S. Tsirkin wrote: >>> On Mon, Dec 24, 2018 at 03:53:16PM +0800, Jason Wang wrote: >>>> On 2018/12/14 ??8:36, Michael S. Tsirkin wrote: >>>>> On Fri, Dec 14, 2018 at 11:57:35AM +0800, Jason Wang wrote:

On 2019/1/7 ??11:28, Michael S. Tsirkin wrote: > On Mon, Jan 07, 2019 at 10:19:03AM +0800, Jason Wang wrote: >> On 2019/1/3 ??4:47, Michael S. Tsirkin wrote: >>> On Sat, Dec 29, 2018 at 08:46:51PM +0800, Jason Wang wrote: >>>> This series tries to access virtqueue metadata through kernel virtual >>>> address instead of copy_user() friends since they had

On 2019/1/7 ??11:28, Michael S. Tsirkin wrote: > On Mon, Jan 07, 2019 at 10:19:03AM +0800, Jason Wang wrote: >> On 2019/1/3 ??4:47, Michael S. Tsirkin wrote: >>> On Sat, Dec 29, 2018 at 08:46:51PM +0800, Jason Wang wrote: >>>> This series tries to access virtqueue metadata through kernel virtual >>>> address instead of copy_user() friends since they had

On Thu, Dec 27, 2018 at 05:39:21PM +0800, Jason Wang wrote: > > On 2018/12/26 ??11:02, Michael S. Tsirkin wrote: > > On Wed, Dec 26, 2018 at 11:57:32AM +0800, Jason Wang wrote: > > > On 2018/12/25 ??8:50, Michael S. Tsirkin wrote: > > > > On Tue, Dec 25, 2018 at 06:05:25PM +0800, Jason Wang wrote: > > > > > On 2018/12/25 ??2:10, Michael S. Tsirkin

On Wed, Dec 26, 2018 at 11:57:32AM +0800, Jason Wang wrote: > > On 2018/12/25 ??8:50, Michael S. Tsirkin wrote: > > On Tue, Dec 25, 2018 at 06:05:25PM +0800, Jason Wang wrote: > > > On 2018/12/25 ??2:10, Michael S. Tsirkin wrote: > > > > On Mon, Dec 24, 2018 at 03:53:16PM +0800, Jason Wang wrote: > > > > > On 2018/12/14 ??8:36, Michael S. Tsirkin

On Wed, Dec 26, 2018 at 11:57:32AM +0800, Jason Wang wrote: > > On 2018/12/25 ??8:50, Michael S. Tsirkin wrote: > > On Tue, Dec 25, 2018 at 06:05:25PM +0800, Jason Wang wrote: > > > On 2018/12/25 ??2:10, Michael S. Tsirkin wrote: > > > > On Mon, Dec 24, 2018 at 03:53:16PM +0800, Jason Wang wrote: > > > > > On 2018/12/14 ??8:36, Michael S. Tsirkin