Here is another small diff that tidys somemore of adduser.
The @message_buffer array is cleared in message_read(), so no
need to clear it just before calling message_read().
Also, make the first call to filetest() display an error message
if a problem is found but not the following ones.
While i
Since nobody with a working PCI_PRODUCT_ATTANSIC_L2C seems interested,
and the devices newly added in this diff are showing up more often
in submitted dmesg than the L2C version matched by the current driver,
I intend to commit this tomorrow unless there are objections.
On 2011/05/16 11:16, Stuar
On Wed, May 18, 2011 at 02:07:28AM +0200, Ariane van der Steldt wrote:
> On Wed, May 11, 2011 at 05:05:32PM +0200, Ariane van der Steldt wrote:
> > On Wed, May 11, 2011 at 03:44:45AM +0200, Ariane van der Steldt wrote:
> > > On Wed, May 11, 2011 at 03:43:19AM +0200, Ariane van der Steldt wrote:
> >
Just upgraded a machine to AMD64, .. and the MB has an NVIDIA nForce MCP
ethernet onboard. Unfortunately, the nfe driver configures but will not
pass traffic.
Before I drop in another card, would any data or troubleshooting be
useful?
Lee
Hi,
When the sparc64 iommu fails to lookup a vaddr, it prints a message and
returns EFBIG. This cannot be recovered from and is usually indicative
of damaged pmap. Therefor, panic right here instead.
Tested on sparc64, where this diff means the difference between dropping
into single-user mode ve
Hi,
Pmemrange being a difficult algorithm and reports of dma controllers
being unhappy with what it serves up, plus some prodding from theo,
caused me to write this little validation step.
Very low overhead, but guaranteed to catch bugs when they happen,
instead of when finally a dma controller d
On Wed, May 18, 2011 at 04:46:01PM +0200, Ariane van der Steldt wrote:
>
> So in the case of a crash, please show me ddb output for:
> show map /f *kernel_map
> This time with an asterisk and not, as in the original mail, without
> one.
In fact kernel_map itself is 0 when my machine stops. So t
> In fact kernel_map itself is 0 when my machine stops. So the command
> above also fails.
[...]
> ddb> x kernel_map
> kernel_map: 0
Use x/qx, you're on a 64-bit platform and this is a 64 bit pointer (of
which the upper 32 bits are zero).
On Wed, May 18, 2011 at 08:08:29PM +, Miod Vallat wrote:
> > In fact kernel_map itself is 0 when my machine stops. So the command
> > above also fails.
>
> [...]
>
> > ddb> x kernel_map
> > kernel_map: 0
>
> Use x/qx, you're on a 64-bit platform and this is a 64 bit pointer (of
> which
Penned by Mark Kettenis on 20110516 4:33.22, we have:
| > Date: Mon, 16 May 2011 10:05:37 +0100
| > From: Stuart Henderson
| >
| > Useful for following http://www.openbsd.org/faq/faq4.html#getdmesg,
| > amongst other things... ok?
|
| Did you build floppies?
This looks to me like he's adding
Penned by Stuart Henderson on 20110516 5:59.19, we have:
| Re http://permalink.gmane.org/gmane.os.openbsd.misc/185629
| To set IPv6 tunnel endpoints for gif/gre, you have to use
| syntax like "ifconfig gif0 inet6 tunnel 1::1 2::2" rather
| than just "ifconfig gif0 tunnel 1::1 2::2".
|
| This is b
"set skip" in PF has a slightly unexpected behaviour; rather
than skipping by interface group, it matches on the non-numeric
part of an interface name.
for example:
ifconfig carp5 group foo -group carp
set skip on carp
-> carp5 is still skipped.
no manpage change included as "set skip" is alrea
> Date: Wed, 18 May 2011 18:41:02 +0200
> From: Ariane van der Steldt
>
> Hi,
>
> When the sparc64 iommu fails to lookup a vaddr, it prints a message and
> returns EFBIG. This cannot be recovered from and is usually indicative
> of damaged pmap. Therefor, panic right here instead.
>
> Tested on
Hi,
It turns out that on sparc64, doing something like
show map /f *kernel_map
in ddb, makes you crash with a nullpointer exception.
Diff below makes sure we read all bytes of the pointer. The int in the
original code also explains why amd64 (little-endian arch) never had a
problem.
To test thi
Hi,
I would respond in-thread, but I can't find the thread that had the
original report that emacs-22 doesn't work under vmmap. Perhaps it was
only on icb...
Anyways, emacs-22.3p8 doesn't work under vmmap on i386. And the lovely
thing is, it's not my bug. :)
Emacs, by way of elf commands, insists
On Thu, May 19, 2011 at 03:32:10AM +0200, Ariane van der Steldt wrote:
> Hi,
>
> I would respond in-thread, but I can't find the thread that had the
> original report that emacs-22 doesn't work under vmmap. Perhaps it was
> only on icb...
>
> Anyways, emacs-22.3p8 doesn't work under vmmap on i386
On Wed, May 18, 2011 at 8:49 PM, Ariane van der Steldt
wrote:
> On Thu, May 19, 2011 at 03:32:10AM +0200, Ariane van der Steldt wrote:
>> Hi,
>>
>> I would respond in-thread, but I can't find the thread that had the
>> original report that emacs-22 doesn't work under vmmap. Perhaps it was
>> only
On Wed, May 18, 2011 at 09:00:25PM -0500, Brad DeMorrow wrote:
> On Wed, May 18, 2011 at 8:49 PM, Ariane van der Steldt
> wrote:
> > On Thu, May 19, 2011 at 03:32:10AM +0200, Ariane van der Steldt wrote:
> >> Hi,
> >>
> >> I would respond in-thread, but I can't find the thread that had the
> >> or
This adds support for SB800+ and is a little easier to understand, but it
probably isn't very pretty.
Information obtained from AMD SB800 datasheets, 45481.pdf/45482.pdf/45483.pdf.
Any comments? I'm not really sure if playing with non-pci I/O space in a PCI
driver makes sense.. but there really i
On 05/18/11 18:32, Ariane van der Steldt wrote:
> It turns out that on sparc64, doing something like
>show map /f *kernel_map
> in ddb, makes you crash with a nullpointer exception.
> Diff below makes sure we read all bytes of the pointer. The int in the
> original code also explains why amd64
20 matches
Mail list logo
