On 15/05/11 1:31 AM, LEVAI Daniel wrote:
This diff completes the implementation of PCI "flags", making sure
[...]
Hi!
Forgive my ignorance, but is PR 6523 related to this? Should I try this
with that machine?
(http://marc.info/?l=openbsd-misc&m=126840264605078&w=2)
Daniel
The PR has no re
> This diff completes the implementation of PCI "flags", making sure
[...]
Hi!
Forgive my ignorance, but is PR 6523 related to this? Should I try this
with that machine?
(http://marc.info/?l=openbsd-misc&m=126840264605078&w=2)
Daniel
--
LIVAI Daniel
PGP key ID = 0x83B63A8F
Key fingerprint =
On Thu, 12 May 2011, Jona Joachim wrote:
> Hi,
> I just wanted to share this board that I discovered today:
> http://dangerousprototypes.com/bus-pirate-manual/
>
> It's an uftdi(4) board that gives you access to the following bus
> protocols:
> 1-Wire, I2C, SPI, JTAG, RS-232, MIDI, ...
> http://d
At the sake of running out of internet here's a little clarification ...
... this ...
-> input channela
channela output ->
-> input channelb
channelb output ->
-> input channelc
channelc output ->
-> input channeld
channeld output ->
-> input groupA (a&b)
groupA (a&b) output ->
-> input groupB (c
Hi.
Sviatoslav Chagaev <0x1392 () gmail ! com>
> I have absolutely no idea. I'm not an audio equipment manufacturer.
I have used many consoles ... digital and analogue ones ... "live" and
in studios.
I also have an electronics background - digital and analogue ... and
repaired many consoles.
I've
On Sat, May 14, 2011 at 07:02:21PM +0300, Sviatoslav Chagaev wrote:
> I always thought that the idea behind the *ctl programs is to provide a
> way to configure totally different things in a similar manner.
> Therefore *ctl programs should behave as similarily as possible.
so where is your diff t
On Sat, May 14, 2011 at 07:29:01PM +0300, Sviatoslav Chagaev wrote:
> On Mon, 9 May 2011 12:44:54 +
> Jacob Meuser wrote:
> > ok then, why do some devices have 'outputs.dac' yet others have
> > 'inputs.dac'? what is the difference to the user? which is more
> > correct? why?
> >
>
> I ha
Please review the diff.
Thanks
Index: usr.bin/ssh/authfd.c
===
RCS file: /cvs/src/usr.bin/ssh/authfd.c,v
retrieving revision 1.84
diff -p -u -r1.84 authfd.c
--- usr.bin/ssh/authfd.c31 Aug 2010 11:54:45 - 1.84
+++ usr.
Hello all.
This patch actually consists of three parts, logically organized
one-by-one down there:
1. Add BIOCLISTCONTROLLERS ioctl to bio(4), allowing to enumerate all
registered controllers.
2. Add "-A" flag to bioctl(8) that enumerates all volumes accessible by
bio(4), and make this default b
On Sat, 14 May 2011 17:55:06 +0200
Alexandre Ratchov wrote:
> On Sat, May 14, 2011 at 06:26:57PM +0300, Sviatoslav Chagaev wrote:
> >
> > Then the only thing that remains -- is to add clipping in mix_badd().
>
> Yes, if the other diff goes in, handling clipping makes sense.
>
> > This will giv
On Mon, 9 May 2011 12:44:54 +
Jacob Meuser wrote:
> On Mon, May 09, 2011 at 02:56:28PM +0300, Sviatoslav Chagaev wrote:
> > On Mon, May 9, 2011 at 4:48 AM, Jacob Meuser
> > wrote:
> > > On Mon, May 09, 2011 at 01:32:49AM +0300, Sviatoslav Chagaev wrote:
> > >> * sorted output looks cleaner,
Most other OSen name this agp_amd64 or similar, no numbers in device
names here. this is a driver for the early amd64s that had an agp slot
which interfaces with the GART on the cpu.
This has been floating around for probably 3 years now, but never got
commited because it conflicted with the amd64
On Mon, 9 May 2011 14:55:36 +0200
Alexandre Ratchov wrote:
> On Mon, May 09, 2011 at 02:56:28PM +0300, Sviatoslav Chagaev wrote:
> > On Mon, May 9, 2011 at 4:48 AM, Jacob Meuser
> > wrote:
> > > On Mon, May 09, 2011 at 01:32:49AM +0300, Sviatoslav Chagaev wrote:
> > >> * sorted output looks clea
On Sat, May 14, 2011 at 06:26:57PM +0300, Sviatoslav Chagaev wrote:
>
> Then the only thing that remains -- is to add clipping in mix_badd().
Yes, if the other diff goes in, handling clipping makes sense.
> This will give aucat all the bits and pieces to meet the requirements
> of all kinds of u
On Fri, 13 May 2011 12:39:43 +0200
Alexandre Ratchov wrote:
> On Thu, May 12, 2011 at 12:36:43AM +0300, Sviatoslav Chagaev wrote:
> > > >
> > > > So, why is what I'm proposing better than what currently exists:
> > > >
> > > > * Resembles how sound behaves in real world more closely;
> > > > *
On Fri, May 13, 2011 at 11:36:48PM +0100, Owain Ainsworth wrote:
> On Mon, May 09, 2011 at 10:15:23PM +0100, Owain Ainsworth wrote:
> > On Mon, May 09, 2011 at 07:22:01PM +0100, Owain Ainsworth wrote:
> > > The new world order of pmemrange makes this data completely redundant
> > > (being dealt wit
On Sat, Apr 16, 2011 at 11:52:34AM -0400, Brad wrote:
> On 08/04/11 6:27 PM, Brad wrote:
> > On Thu, Apr 07, 2011 at 09:00:45PM -0400, Brad wrote:
> >> Some _LP64 ifdef's leftover from rev 1.1. They appear to be unnecessary
> >> since this code is only for amd64 anyway and thus a 64-bit arch.
> >
On Fri, May 13, 2011 at 11:43:53AM +0200, Jasper Lievisse Adriaanse wrote:
> On Thu, May 12, 2011 at 06:00:53PM +, Jona Joachim wrote:
> > Hi,
> > I just wanted to share this board that I discovered today:
> > http://dangerousprototypes.com/bus-pirate-manual/
> >
> > It's an uftdi(4) board tha
> Date: Sat, 14 May 2011 12:02:45 +0200 (CEST)
> From: Mark Kettenis
>
> Another small piece of the puzzle. I'd appreciate it if people could
> give this a quick test on their machines. If you have working
> suspend/resume, please make sure it doesn't break with this diff.
>
> Index: pci.c
> =
Mark Kettenis wrote:
> Index: pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/pci.c,v
> retrieving revision 1.89
> diff -u -p -r1.89 pci.c
> --- pci.c 12 Apr 2011 20:29:35 - 1.89
> +++ pci.c 13 May 2011 21:05:11 -
>
Another small piece of the puzzle. I'd appreciate it if people could
give this a quick test on their machines. If you have working
suspend/resume, please make sure it doesn't break with this diff.
Index: pci.c
===
RCS file: /cvs/sr
On Sat, May 14, 2011 at 4:22 AM, Otto Moerbeek wrote:
> On Sat, May 14, 2011 at 04:15:51AM -0500, Abel Abraham Camarillo Ojeda
wrote:
>
>> On Sat, May 14, 2011 at 4:08 AM, David Gwynne wrote:
>> >
>> >
>> > i have had a look at querying disks for their physical and logical block
>> alignments and
On Sat, May 14, 2011 at 04:15:51AM -0500, Abel Abraham Camarillo Ojeda wrote:
> On Sat, May 14, 2011 at 4:08 AM, David Gwynne wrote:
> >
> >
> > i have had a look at querying disks for their physical and logical block
> alignments and offsets, but the the WD??EARS-00? drives dont report this info
On Sat, May 14, 2011 at 4:08 AM, David Gwynne wrote:
>
>
> i have had a look at querying disks for their physical and logical block
alignments and offsets, but the the WD??EARS-00? drives dont report this info.
according to western digital, the next generation of these drives
(WD??EARS-11? iirc) a
On 14/05/2011, at 6:43 PM, Abel Abraham Camarillo Ojeda wrote:
>
> I'm starting to get angry about the _horrible_ performance on this drive
> (WD10EARS-00Y), some developer ever got a chance to see something about
> this?
don't get angry, it's just a disk.
we changed the default alignment of part
On Sat, May 14, 2011 at 03:43:23AM -0500, Abel Abraham Camarillo Ojeda wrote:
> > (( If you read this far, have a cookie
> >and wonder with me about that quick extraction...
> >The system this drive is in has the same board,
> >but everything else is slower and not idle when meassured
List: openbsd-tech
Subject:impact of unaligned partitions/slices on 4kB sector drives
(wd10ears)
From: Robert
Date: 2010-01-06 22:54:34
Message-ID: 20100106235434.55963d32 () openbsd ! pap ! st
> Hello,
>
> i did some measurements on the impact that unaligned partitions/slic
27 matches
Mail list logo
