Guenther Niess pappanoa.de> writes:
> sh: pcidump: not found
> sh: acpidump: not found
> b64encode: *: No such file or directory
>
> pcidump:
>
> acpidump:
Looks like sendbug needs a tweak to take platforms without
pcidump/acpidump/b64encode in account.
Ilmari Jaaranen kapsi.fi> writes:
> [demime 1.01d removed an attachment of type application/octet-stream which
had a name of dmesg]
>
> [demime 1.01d removed an attachment of type application/octet-stream which
had a name of messages]
you better send dmesg and co inline.
Sergey Bronnikov gmail.com> writes:
> panic: ehci_device_clear_toggle: queue active
Seems to be similar case as in another bug report.
http://article.gmane.org/gmane.os.openbsd.bugs/19812/
Lightning Dust outlook.com> writes:
> twe driver documentation does not list support for 3ware 9550SE device, but
> this device is working.
>
> Is this the correct place to report this issue?
dmesg and one-liner diff to man page would be nice.
Jan Vlach volny.cz> writes:
> The machine did not crash to kernel panic, but lost network connectivity
over night running 5.3-current.
>
> I was able to log in to system console, there was nothing unusual in the
logs. I did the reboot to verify that
> there are no problems with the VPS provider
Matthew Heyse mtu.edu> writes:
> I captured the Dmesg from a virutal com port conection (Named Pipe) to
> a VPC running XP with hyper terminal.
Given that
> softraid0 at root
> scsibus1 at softraid0: 256 targets
> root on rd0a swap on rd0b dump on rd0b
that
> softraid0 at root
> root on rd0a
Theo de Raadt cvs.openbsd.org> writes:
> If these VM's are real VM's the should start emulating the machines
> they claim to be emulating correctly, or they should start advertising
> that they are something "different", so that we can isolate the bullshit
> factor.
Ok. I see.
Could we trim tha
Mike Larkin azathoth.net> writes:
> You're kidding, right?
Could you guys tell what exactly wrong with FreeBSD/NetBSD approach?
Jonathan Gray jsg.id.au> writes:
> Filling the kernel full of if not really running on hardware
> do something else paths is asking for trouble. If a hypervisor
> claims to be a specific model of a processor it should not be
> surprised when it gets msrs that processor can handle.
>
>
FreeBSD
Jonathan Gray jsg.id.au> writes:
> > So what is the point for guest to run erratas if hypervisor
> > may already done that upwards?
>
> Filling the kernel full of if not really running on hardware
> do something else paths is asking for trouble. If a hypervisor
> claims to be a specific model o
Jonathan Gray jsg.id.au> writes:
> That is quite a large hammer. It would be preferable to
> find out which msr it objects to and guard it with a specific cpuid
> check, and/or fix the hypervisor.
>From NetBSD PR/47677 (http://gnats.netbsd.org/47677)
"I think x86_errata should be avoided if Ne
Stefanus Hermawan yahoo.com> writes:
> I have compile new kernel, my device detected, but not working.
Could you post a new dmesg (for a kernel with diff applied)
and tell exactly what is "not working". ifconfig -a will be
useful too.
Jonathan Gray jsg.id.au> writes:
> {{ USB_VENDOR_UNKNOWN4, USB_PRODUCT_UNKNOWN4_DM9601 }, 0 },
> + {{ USB_VENDOR_UNKNOWN4, USB_PRODUCT_UNKNOWN4_DM9601_2 }, 0 },
> {{ USB_VENDOR_UNKNOWN6, USB_PRODUCT_UNKNOWN6_DM9601 }, 0 }
USB_VENDOR_[UNKNOWN4|UNKNOWN6] are most likely re-branded D
Sif-Allah TOUIL gmail.com> writes:
> There is a sound chips on my motherboard, it is the chipset integrated
> Realtek AL883 and he is not used, maybe it is not reconiez. Instead it is
> the video card who is use, but i do not have sound :
>
> azalia0 at pci2 dev 0 function 1 "ATI Radeon HD 3600
Christophe StaC/esse skynet.be> writes:
> To solve the problem temporarily I've simply changed the types of the
> arguments and the return type of aml_evalexpr to u_int64_t. And now,
Hey.
Could you provide diff -u so other people can try this out?
> (SB.PCI0.SBRG.EC0) is prefixed by several ba
viq viq.ath.cx> writes:
>
> After suspend-unsuspend none of the USB ports on my ThinkPad x201 work.
> Attached dmesg, usbdevs, and pcidup - the last one both before and after
> suspend, as there is a minor difference, that I'll paste below:
>
> --- pcidump_before Tue Jan 31 18:10:04 2012
>
Theo de Raadt cvs.openbsd.org> writes:
> > --- pcidump_before Tue Jan 31 18:10:04 2012
> > +++ pcidump_after Tue Jan 31 18:33:01 2012
> > @@ -159,7 +159,7 @@
> > 0x0014:
> > 0x0018: Primary Bus: 0 Secondary Bus: 2 Subordinate Bus: 2
> > Secondar
17 matches
Mail list logo
