Hello. We were seeing this issue with FFS and softdep, no wapbl under
5.x. Would these patches help that? It looks like not, but I'm a litle
unclear about that.
-thanks
-Brian
On Jan 13, 10:45am, David Holland wrote:
} Subject: Re: rename(), wapbl and deadlock
} On Thu, Dec 17, 2009 at 1
hello. What happens if you boot without acpi? (boot -2)
This looks like a problem similar to one I had with my Dell laptop. I
filed a pr about it. See below.
Does this help?
-Brian
Hello. Well, it turns out that there isn't a fix in the BIOS for this
problem, but I was able t
hello. I'm a big fan of vmstat -i because it tells me what my current
per-second interrupt load is, and, hopefully, where the interrupts are
going. If you're having trouble listening to audio and getting disk
timeouts, then I think you're undergoing some kind of interrupt storm which
need
Hello. The easiest and most reliable way to get a serial console is
to use the installboot(8) program with the -o option. This method has
worked as long as I remember, and that's been quite a long time.
Steps:
1. cd /usr/mdec on the target machine
2. installboot -v -o console=com0 /de
Hello. You're correct. Any kernel that has serial support in it,
i.e. device com* at something, will be able to use any of those serial
devices as console assuming the bios sets the device up at boot time, and
you can tell the boot loader to use that device as a serial console. I use
ser
Hello. If it's been runing solidly for a while, I'd be suspicious of
the hardware. Especially if you've not made any changes recently.
-thanks
-Brian
Hello. It's possible the problem is not memory. It could be one of
the controller chips as well. Especially since the errors were preceeded
by scsi allocation errors from the scsi controller. Unfortunately, such
errors can be hard to diagnose.
-Brian
On Apr 8, 6:57pm, Edgar =?iso-8859
Peter Reimers" wrote:
} Subject: AW: AW: Gdb and lkm modules with NetBSD-5
} This is a multi-part message in MIME format.
}
} --_=_NextPart_001_01CA693D.5BB2BEA6
} Content-Type: text/plain;
} charset="iso-8859-1"
} Content-Transfer-Encoding: quoted-printable
}
} Hi,
}
} B
Hello. I'd say use tcp. Gdb already supports it, so half the work is
done. More than that, if, in fact, you can use a small tcp implementation
inside the debugged kernel.
On Jun 5, 6:28pm, Jordan Gordeev wrote:
} Subject: remote kernel debugging over a network
} Hello, kernel hackers!
}
Hello. Having just recently spent quite a bit of time porting a kernel
module from NetBSD-3 to NetBSD-5, and working out a bunch of
synchronization issues, I suggest skipping over NetBSD-4 and going straight
for 5. You'll get better multi-cpu capability, and it looks like the
locking APIs
Hello David. If your supposition is correct, it looks to me like
things should behave the way you expect under NetBSD-4 and NetBSD-5. The
The line:
pti->pt_send = 0;
is not there under NetBSD-5 or NetBSD-4.
Have you tried your test there?
-Brian
On Sep 2, 12:06pm, David Young wrote:
} Su
Hello. I submitted a couple of patches for kern/40018, hardware
checksum failures on bge(4) controlled chips, which fix the problem. These
patches have been running on a number of high volume production servers for
a week with babsolutely no problems and all hardware capabilities enabled
Lancelot Simon wrote:
} Subject: Re: Fixes for kern/40018 -- any chance of getting these pulled in
} On Tue, Sep 21, 2010 at 10:05:52AM -0700, Brian Buhrow wrote:
} >
} > Hello. I submitted a couple of patches for kern/40018, hardware
} > checksum failures on bge(4) controlled chips,
;m happy to feed you test kernels if
that makes it easier.
-Brian
to
probably not the right choice. :)
On Sep 21, 3:49pm, Thor Lancelot Simon wrote:
} Subject: Re: Fixes for kern/40018 -- any chance of getting these pulled in
} On Tue, Sep 21, 2010 at 12:08:02PM -0700, Brian Buhrow wrote:
} >
what i did=
} to handle the bcm5721. I still have a couple of those to check against.
}
} cheers,
} --Jonathan
}
} --- On Tue, 9/21/10, Brian Buhrow wrote:
}
} From: Brian Buhrow
} Subject: Fixes for kern/40018 -- any chance of getting these pulled into th=
} e -current and 5.x trees?
} To:
Hello. Excellent! Let me know if you have trouble getting the
patches from the bug report and/or getting them into a kernel.
-thanks
-Brian
isses
6158353 datagrams output
On Sep 25, 10:56am, Sverre Froyen wrote:
} Subject: Re: Fixes for kern/40018 -- any chance of getting these pulled in
} On Tue September 21 2010 18:09:08 Brian Buhrow wrote:
} > Hello. Excellent! Let me know if you have trouble getting the
} > patches f
Hello thor. Do these test results help allay your concerns? Sverre's
chip is the 5701, one I thought you said would be important to test.
Would someone be willing to commit this and pull it up to the 5.x
branches if Thor gives his blessing? Does anyone else have concerns that
we
meone would be willing to work with me to give
me commit privileges?
-thanks
-Brian
On Sep 27, 10:36am, Sverre Froyen wrote:
} Subject: Re: Fixes for kern/40018 -- any chance of getting these pulled in
} On Mon September 27 2010 10:18:48 Brian Buhrow wrote:
} > Hello Sverre. While doing your
hello. Just following up to see if anyone else has tried these
patches and found any troubl with them? I believe all reports thus far
have been favorable.
If the reports are good, could someone commit these to the source
tree and request the appropriate pullups? Alternatively, if
e.
-thanks
-Brian
On Oct 20, 9:44am, Martin Husemann wrote:
} Subject: Re: Fixes for kern/40018 -- any chance of getting these pulled in
} On Tue, Oct 19, 2010 at 10:26:36PM -0700, Brian Buhrow wrote:
} > tree and request the appropriate pullups? Alternatively, if someone wishes
} > to work w
Hello. Is this something you can reproduce easily? I wonder if the
ethernet chip is just hanging, and the rest of the machine is fine?
Which bits are you turning on? just:
ip4csum, tcp4csum and udp4csum?
If the two machines have different revisions of the chip, that
could explain
hello. Thanks for this patch. I've been thinking about some other
patches for raidframe, and thought I'd share my thoughts with the list.
These patches reminded me that I wanted to write down these thoughts, and
since you're in the code already, Matt, I thought you might have some
immedi
Hello. Following up on the first question in this thread, see below
with comments and questions.
On Nov 8, 10:41am, Greg Oster wrote:
} > 1. Raidframe autoconfigure on raw disks.
} > From what I can tell, raidframe can't autoconfigure on a disk
} > unless the disk has either a BSD dis
Hello. Following up on my earlier post, see below.
On Nov 8, 4:38pm, Brian Buhrow wrote:
} Hello. Below is a patch which implements this idea. I've tested it
} on systems with raids configured on raw disks, where autoconfigure didnt
} work before this patch, on systems
Hello martin. Any news on tracking this issue? Just curious.
-thanks
-Brian
On Oct 30, 12:44pm, Martin Husemann wrote:
} Subject: Re: Fixes for kern/40018 -- any chance of getting these pulled in
} On Fri, Oct 29, 2010 at 04:32:28PM -0700, Brian Buhrow wrote:
} > Hello. Is t
Hello. I have a question about this. If I understand what this
change does correctly, you're trying to keep the hardware watchdog from
firing while you're in DDB, right? The question is, is this an optional
change? That is, can I change the behavior on the fly while the machine is
runni
Hello. I'm hoping someone can shed light on this problem and that I'm
just missing something way too obvious to notice.
I have a backup server which was running NetBSD-3, then NetBSD-4, and
finally NetBSD-5. I noticed that my backups began taking 2 to 3 times
longer when I switche
hello. Following up on my own post, I discovered that I can change
the window size by adjusting the sysctl variable:
net.inet.tcp.recvspace
The table below shows the settings of this variable compared with the
window size I get.
net.inet.tcp.recvspace window size
32768
CP Window size under NetBSD-5???
} On Thu, 23 Dec 2010, Brian Buhrow wrote:
}
} > The trace shows that the initial window size is correct, but that when
} > subsequent packets are generated, the window size drops to the numbers shown
} > above. This makes me think that the calls to sores
Hello. I have a box running NetBSD-5.1/i386 with kernel sources from
1/4/2011 which refuses to reconstruct to what looks like a perfectly good
disk. The errormessages are:
Command:
root#raidctl -R /dev/sd10a raid2
Error messages from the kernel:
raid2: initiating in-place reconstruction
gic to turn off -werror for individual kernel
builds?
-thanks
-Brian
On Jan 6, 11:50am, Greg Oster wrote:
} Subject: Re: Problems with raidframe under NetBSD-5.1/i386
} On Thu, 6 Jan 2011 09:42:41 -0800
} buh...@lothlorien.nfbcal.org (Brian Buhrow) wrote:
}
} > Hello. I have a box running NetBS
ow yet.
-thanks
-Brian
On Jan 6, 3:56pm, Greg Oster wrote:
} Subject: Re: Problems with raidframe under NetBSD-5.1/i386
} On Thu, 6 Jan 2011 10:05:17 -0800
} buh...@lothlorien.nfbcal.org (Brian Buhrow) wrote:
}
} > hello Greg. When the component failed, I just got an error:
} > raid2:
Hello. Ok. I have more information, perhaps this is a known issue.
If not, I can file a bug.
the problem seems to be that if you partition a raid set with gpt
instead of disklabel, if a component of that raid set fails, the
underlying component is held open even after raidframe
Hello. Trying a quick patch now. Will post answers tomorrow.
-thanks
-Brian
On Jan 6, 8:49pm, Greg Oster wrote:
} Subject: Re: Problems with raidframe under NetBSD-5.1/i386
} On Thu, 6 Jan 2011 18:33:58 -0800
} buh...@lothlorien.nfbcal.org (Brian Buhrow) wrote:
}
} > Hello.
Hello. Well, the following pseudo patch doesn't work. While it might
fix a problem, the specific problems I'm having aren't related to this one,
or, at least, they don't seem to be. However, I'll post the change I made,
based on Greg's suggestion, incase I got the wrong idea.
-Brian
i
hello. OK. Still more info.There seem to be two bugs here:
1. Raid sets with gpt partition tables in the raid set are not able to
reconstruct failed components because, for some reason, the failed
component is still marked open by the system even after the raidframe code
has marked it d
hello. For bug #2, as previously written, I've filed pr kern/44340,
including the patch that fixes it. If this could get pulled up to
NetBSD-5, that would be wonderful.
-thanks
-Brian
On Jan 7, 5:34am, Brian Buhrow wrote:
} Subject: Re: Problems with raidframe under NetBSD-5.1
ill come to me. Hopefully it's as
easy a fix as the fix for kern/44340 was.
-Brian
On Jan 7, 2:17pm, Greg Oster wrote:
} Subject: Re: Problems with raidframe under NetBSD-5.1/i386
} On Fri, 7 Jan 2011 05:34:11 -0800
} buh...@lothlorien.nfbcal.org (Brian Buhrow) wrote:
}
} > hello. OK
2011 05:34:11 -0800
} buh...@lothlorien.nfbcal.org (Brian Buhrow) wrote:
}
} > hello. OK. Still more info.There seem to be two bugs here:
} >
} > 1. Raid sets with gpt partition tables in the raid set are not able
} > to reconstruct failed components because, for some reason, t
but not when I create the
raid, I'm all ears.
-thanks
-Brian
On Jan 7, 3:22pm, Brian Buhrow wrote:
} Subject: Re: Problems with raidframe under NetBSD-5.1/i386
} hello Greg. Regarding problem 1, the inability to reconstruct disks
} in raid sets with wedges in them, I confess I don&#
Hello. Here's a silly thought. Can't you determine whether a disk is
in a raid set by looking at the components in a logical volume and
subtracting them from the list of disks on the controller? Then, only read
and reset the mode pages on those disks which don't appear in any logical
vol
they
build a custom kernel with the magic option turned on, and they'd be off to
the races. Not ideal, but certainly better than where we are now.
-Brian
From: buh...@lothlorien.nfbcal.org (Brian Buhrow)
Date: Thu, 13 Dec 2007 22:56:33 -0800
Subject: A fix for ACPI BIOS's which route inte
, 8:03am, Greg Oster wrote:
} Subject: Re: Problems with raidframe under NetBSD-5.1/i386
} On Thu, 20 Jan 2011 17:28:21 -0800
} buh...@lothlorien.nfbcal.org (Brian Buhrow) wrote:
}
} > hello. I got side tracked from this problem for a while, but
} > I'm back to looking at it as I
Hello. See below.
I really don't get why the creation of the raid set would have
succeeded before, but not afterwards Was the RAID set created in
single-user mode or from sysinst or something? Is there some
'securelevel' thing coming into play? I'm just guessing here, as this
makes
Hello. As of NetBSD-5.0, I can run FreeBSD statically linked binaries
without a problem. I'm using the FreeBSD binary of t_cli, as someone else
is, and it says the following:
#file /usr/local/sbin/tw_cli
/usr/local/sbin/tw_cli: ELF 32-bit LSB executable, Intel 80386, version 1
(FreeBSD),
hello. I would suggest marking sd0a as failed, as you indicate in
your second scenario, then, after replacing the failed sd0 with the new
sd0, doing:
raidctl -R /dev/sd0a raid0
or what ever the magic raid number is in your setup.
That should get you back to what you want with the least nu
Hello. If the new disk has the same bus and target numbers, it will
reset as sd0 and you won't see a new disk, but a restored existing disk.
Of course, at this point, you'll have to re-partition and/or disklabel it,
before you do your raidctl -R /dev/sd0a raid0, but once you do those
ste
Hello Martin. Doesn't boot -a already do this by allowing you to
select the root filesystem and the init path? I'm certain I've booted
systems running with raid roots off of cdroms for repair purposes.
-Brian
On Apr 18, 7:41am, Martin Husemann wrote:
} Subject: New boothowto flag to pr
Hello. I think he's trying to draw a distinction between 4.3BSD
(UFS1) FFS
filesystems, as produced by newfs -O 0 and 4.4BSD filesystems (UFS2, also
known as FFS-V1), as produced by -O 1 and 4.4BSD (FFS-V2) filesystems, as
produced by newfs -O 2.
I take it from this discussion that
Hello. I've got anew system I'm building where I have interrupt
issues with with the GENERIC kernel. This is an amd64 system with
NetBSD-5.1 with sources as of about 3 weeks ago.
The INSTALL kernel works fine, but when I boot the GENERIC kernel, the
ethernet doesn't work. I get a
on't
get routed properly?
-thanks
-Brian
On May 12, 11:54pm, Manuel Bouyer wrote:
} Subject: Re: Interrupt issues with amd64 and an IXSystems 1U server (5.1)
} On Thu, May 12, 2011 at 12:12:54PM -0700, Brian Buhrow wrote:
} > Hello. I've got anew system I'm building where I ha
Hello. Thanks for the patch. Although this is a SuperMicro board, it
still doesn't work. I'll try to get the diffs between the working and
non-working dmesg outputs to the list in the next couple of days. Maybe
someone will spot something I missed.
-thanks
-Brian
hello. Here is a diff of the dmesg output from a
working GENERIC-INSTALL kernel versus the non-working GENERIC kernel. The
only oddities I see are that there is an extraneous ukphy physical
interface attached to wm0 in the GENERIC kernel, while the ukphy is
attached to the wm1 chip on th
Hello. I've had a breakthrough on this issue. The problem seems to
be with the wm(4) driver and this particular chip, an 82576 1000-base-T gigabit
chip. If I enable checksum flags the chip stops responding. If I disable
those flags and re-assign the IP address, things come back to life.
Hello. I like this explanation. Can you help clarify by giving a
theoretical example?
-thanks
-Brian
On Jun 6, 9:50am, Thor Lancelot Simon wrote:
} Subject: Re: RAID stripe size (was: 5.1 RAID5 write performance)
} On Mon, Jun 06, 2011 at 03:24:15PM +0200, Edgar Fu? wrote:
} > > Ah, yes,
Hello. I'm sure this is a pilot error question, but I'm wondering if
someone can enlighten me as to why the behavior I'm seeing is happening.
It's not obvious to me, but I'm sure I'm missing something obvious.
My understanding of ktrace(1) and the associated ktrace(2) call is
that
, 2011 at 12:32:25PM -0700, Brian Buhrow wrote:
} > I don't think this is a bug as it behaves this way on NetBS-3.x, 4.x and
} > 5.x. Can anyone provide clue?
}
} Check the group memberships of the processes?
}
} --
} David A. Holland
} dholl...@netbsd.org
>-- End of excerpt from David Holland
hello. Ok. I figured out the answer. And, yes, it's obvious, as I
suspected.
Mouse had it right. The problem is that both sshd and imapd, the two
processes I was interested in looking at, while not having the setuid or
setgid bits set in the filesystem, do perform a setuid(2) a
Lancelot Simon wrote:
} Subject: Re: Silly question about ktrace(1) and non-root users
} On Tue, Jun 21, 2011 at 07:55:37AM +0100, David Laight wrote:
} > On Mon, Jun 20, 2011 at 04:29:05PM -0700, Brian Buhrow wrote:
} >
} > > For reference, I used the ktrcanset() function from kern_k
hello. On a NetBSD-4.x system, I know of no way to re-enable the SATA
port short of rebooting. Once rebooted, of course, you'll be able to
rebuild your raid and start counting those uptime days again.
-Brian
On Aug 2, 2:53pm, Edgar =?iso-8859-1?B?RnXf?= wrote:
} Subject: Re: SATA: lost
Hello. I don't know about others, but I rely heavily on the daily and
weekly scripts to clean out /tmp and /var/tmp, and have done so for many
years. I'm always creating temporary files I don't need for long periods
of time, but don't want them to necessarily disappear immediately. The
c
Hello. Can you use the mlock(2) system call for this purpose? This
looks like just what it was intended for.
Does it actually work in our system?
-Brian
On Sep 5, 7:37am, Emmanuel Dreyfus wrote:
} Subject: Re: netbsd-5 deadlocks when memory is low
} On Fri, Sep 02, 2011 at 06:54:55AM +
Hello. Are you seeing this behavior in NetBSD-5? I've been working
on porting ufs fixes from David Holland back into 5.x, and I've seen too
many unlocks taken on a given file, and have been wondering where they
come from. I'm not sure it's the same bug, but your finding sounds
interest
hello. I've been running the following chips under NetBSD 4.x for a
number of years at 100mbits/sec without any problems at all. However,
recently, when I tried to link one of these up to a gige port on a Cisco
ME3400 switch, it failed to establish link. If left to autonegotiate, it
esta
Hello. Is that right? I have:
NetBSD pgsql.via.net 4.0_STABLE NetBSD 4.0_STABLE (X2200_MP) #0: Mon May
19 08:3 2:25 PDT 2008
buh...@lothlorien.nfbcal.org:/usr/src/sys/arch/i386/compile/X2200_MP i386
and,
kern.ipc.shmmax = 535019520
kern.ipc.shmmaxpgs = 130620
Which I set with /etc/sy
lease.
-thanks
-Brian
On Nov 24, 8:38pm, Joerg Sonnenberger wrote:
} Subject: Re: SHMMAX runtime setting for Postgres Installation
} On Thu, Nov 24, 2011 at 11:03:59AM -0800, Brian Buhrow wrote:
} > Hello. Is that right? I have:
} >
} > NetBSD pgsql.via.net 4.0_STABLE NetBSD 4.0_STABL
Hello. Upon further investigation, I believe I've found my problem
and I believe it exists in the mii layer of our code. I'm going to
investigate and try to verify my theory before I blather on this list, but
could you send me the output of ifconfig for the device you reference when
its p
ely sure I understand all the moving
parts, so I'd like to know without yet saying for sure where I think the
trouble is.
-thanks
-Brian
On Nov 26, 4:26pm, Manuel Bouyer wrote:
} Subject: Re: wm(4) won't negotiate 1000-base-T with Cisco switches and won
} On Sat, Nov 26, 2011 at 07:08:35AM
Hello. You're right. I think 1000-base-T half-duplex can be used,
but in practice it won't be because the standards say that in order to
establish a 1000-base-T link, you must autonegotiate, and most (all?)
1000-base-T NICs, whether they be in switches or host computers, support
full-dupl
Hello. It turns out that this problem is the same as kern/20700.
I've written a patch which addresses this bug and submitted it to the pr.
If no one objects, I'll commit this patch in a few days and request a
pullup to the 5.x branch. If there are objections, I'm happy to discuss
and/or i
Hello. You've probably gotten a bunch of answers to this question by
now, but the answer is that NetBSD doesn't support using disklabels on
disks or partitions which are more than 2TB in size. Instead, use gpt
wedges to do it.Reat the gpt(8), dkctl(8) man page and look at the NetBSD
how
Hello. Just for your edification, it is possible to break out of fsck
mid-way and reinvoke it with fsck -y to get it to do the cleaning on its
own.
With regard to your notes on speed with NetBSD versus OpenBSD, I
suspect the speed trade off is where the difference is. Op
Hello. I notice that most, if not all, of the network drivers in
NetBSD have interface counters which they use to track things like
collisions, CRC errors, framing errors, etc. It looks like these counters,
and the framework for displayng these counters has been in NetBSD for well
over 10
ces, is there a reas
} On Sat, Dec 10, 2011 at 05:04:41AM -0800, Brian Buhrow wrote:
} > Hello. I notice that most, if not all, of the network drivers in
} > NetBSD have interface counters which they use to track things like
} > collisions, CRC errors, framing errors, etc. It looks
Hello. I haven't yet started, but it is in my grand plan of things to
do. I was instrumental in getting the current zaptel packages runing and
released for NetBSD-3.x, and I subsequently got them working under
NetBSD-5.x in multi-processor mode, where we use them as part of my day
job. I
hello. When I did the work to get the zaptel drivers running under
NetBSD-5.x, I used condiition variables and mutexes to get the job done.
It was a fairly large mechanical job to get things going, but conceptually,
it was pretty simple, and once I got the basic formats right, everything
r
Hello. I'm with Thor. Do what you need to inside the driver itself.
The idea is to make the driver work with the NetBSD kernel, not the NetBSD
kernel work with the driver.
-Brian
On Jan 9, 10:16pm, Brian Buhrow wrote:
} Subject: Re: Equivalent of FreeBSD kernel semaphore?
}
Hello. I'm wondering if anyone has worked on a port of the tpm(4)
driver from FreeBSD or OpenBSD? I realize it's a litle late, but it seems
like a nice thing to have in NetBSD-6.
Thoughts?
-thanks
-Brian
hello. pstat -v should give you what you want to know.
-thanks
-Brian
On Jan 16, 1:17pm, Emmanuel Dreyfus wrote:
} Subject: Re: PUFFS and existing file that get ENOENT
} On Mon, Jan 16, 2012 at 02:02:41PM +0100, Adam Hamsik wrote:
} > Just try to lower that number to some smaller one ?
hello. I've been using NetBSD in server environments, including file
server environments, for 15 years. To me, the fact that you're still
running NetBSD-4 aand you've been able to get everything back in working
order after a series of unfortunate events, presumably after the machine
has r
If you are going to disable COMPAT_FREEBSD in GENERIC kernels, then
you probably also need to disable twe(4) and twa(4) as well. I would not
be in favor of this. Several people have written saying they use tw_cli.
I've not written, but I too use tw_cli to manage 3ware cards under NetBSD.
ee as
unfortunate.
-Brian
On Feb 13, 9:25pm, Eric Haszlakiewicz wrote:
} Subject: Re: Removal of compat-FreeBSD
} On February 13, 2015 6:46:52 PM EST, Brian Buhrow wrote:
} > If you are going to disable COMPAT_FREEBSD in GENERIC kernels, then
} >you probably also need to disable twe(4) an
hello. Here is a very naive question. Could the vga driver be
altered to not do its mapping until the Radeon, or other graphics driver,
has had a chance to map and/or attach?
To solve the loss of the printed copyright messages, perhaps a buffer
could be allocated, much like the d
Hello. It is probably not completely relevant in the NetBSD case, but
I wonder if it might be useful to know how other OS's do this sort of
thing, i.e. Solaris or Linux? That doesn't mean you have to do it as they
do, but Solaris, for one, seems like it's solved a lot of these issues, and
hello. There is a proposal around to drop support for old NetBSD
binaries in current ersions of NetBSD. For example, nuking COMPAT_NOMID,
COMPAT_10, COMPAT_12, COMPAT_13 COMPAT_14, etc. from the the -current
source tree. I'll let the original poster post his reasons for this
proposal on
hello folks. Perhaps someone on this list can enlighten me as to
where I'm going wrong, but I think there may be an issue with ugen(4) when
using the bulk read ahead and write behind code in conjunction with file
descriptors which are in O_NONBLOCK mode. This is with NetBSD/i386 5.2
with
On Sep 24, 12:00pm, Nick Hudson wrote:
} Are you sure about this? I'm not sure why ugen_bulkra_intr doesn't start
} a new transfer, but see below.
}
} I wonder if
}
} http://nxr.netbsd.org/xref/src/sys/dev/usb/ugen.c#697
} http://nxr.netbsd.org/xref/src/sys/dev/usb/ugen.c#1221
On Sep 24, 3:55pm, Nick Hudson wrote:
} Subject: Re: Potential problem with reading data from usb devices with uge
} On 09/24/15 15:52, Brian Buhrow wrote:
} > I forgot to mention the libusb1 calls do request the
} > USB_SET_SHORT_XFER via ioctl(2).
} This doesn't matter / h
hello. I don't necessarily need the read ahead functionality, though
it might be useful when I start doing large transfers to and from the Apple
devices. However, what I want is the non-blocking functionality which,
according to the manual, requires I use the read ahead code to get. It
a
hello. In looking further at the ugen(4) driver, it looks like there
has been some effort to get things like select/poll(2) working with ugen(4)
connected devices, as well as having read calls return after a specific
timeout interval. Under 5.2, at least, and I think -current as well, I
d
Hello. I've been making progress on this issue and have now run into
another issue which folks may be able to shed some light on.
First, where I am.
I've modified the ugen(4) driver to read from devices asynchronously
using a callout, allowing me to issue non-blocking read reques
On Nov 5, 9:07pm, Nick Hudson wrote:
} Subject: Re: Potential problem with reading data from usb devices with uge
} On 05/11/2015 18:53, Brian Buhrow wrote:
} > Hello. I've been making progress on this issue and have now run into
} > another issue which folks may be able to shed
Hello. Another question about the read ahead and write behind code
in ugen(4). It seems that if a write call comes in with a block of data,
and a second write call comes in with a second block of data before the
first block of data has been written to the USB device, the two blocks of
da
uldn't do that?
-thanks
-Brian
On Nov 7, 6:47am, Greg Troxel wrote:
} Subject: Re: Potential problem with reading data from usb devices with uge
} --=-=-=
} Content-Type: text/plain
}
}
} Brian Buhrow writes:
}
} > Hello. Another question about the read ahead and write behind co
Hello. Have you ruled out a hardware problem? Also, are you running
with WAPBL or just straight FFS?
-thanks
-Brian
hello. What constitutes a large file in WAPBL parlents? I've seen
mail servers that deal with files up to 4GB in size. What about database
servers that can have files of multiple GB in size?
-thanks
-Brian
hello. I'm still working away on this ugen(4) driver and I've made a
lot of progress on it. I now have an implementation question which I'd
like to discuss. This message is a little long, and I apologize in advance
for the verbosity, but I want to give as much background as I can so that
ext/plain
} Content-Transfer-Encoding: quoted-printable
}
}
} Brian Buhrow writes:
}
} > The read ahead and write behind code in the ugen(4) driver transfer
} > data from the USB device in question to the user process or from the user
} > process to the USB device respectively. Eac
Hello. I'm making a lot of progress over here on this improved
driver. I have a question that I am not finding the answer to easily and
I'm hoping someone can point me in the right direction.
It's possible for USB transfers to be 16384 bytes in length. Our USB
system seems to pr
1 - 100 of 330 matches
Mail list logo
