>I believe I had this conversation with Justin Gibbs earlier; he told
>me that the callout consumers (network, cam) had to be aware of the
>race and handle this if it matters. I don't particularly like complicating
>the callout handlers as illustrated above, though, so if a better scheme
>is po
> Today's current gave me the following error while building a new kernel
> after a successful make world.
>
> cd /usr/src/sys/modules ;
> MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/PIII850N/modules
> KMODDIR=/boot/kernel MACHINE=i386 make cleandir
> ===> 3dfx
> ===> accf_data
> ===> accf_http
> ===>
> Apparently Makefile not have aicasm target (newly created clean
> building directory):
I can't reproduce this here. My kernel Makefile includes an aicasm target.
--
Justin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
> Well, I ended up unlinking it from the build and am installing now.
> Once I get a fresh world installed, I'll try and rebuild world again
> to see if the problem persists. Would you like me to get a ktrace of
> aicasm running before I rebuild world? -sc
That would have been interesting.
--
>
> uhm, i just got another one. i guess the hd is broken and also managed to
> cause the previous panic.
Can you do a:
cd /usr/src/sys/i386/compile/MYKERNEL
gdb -k kernel.debug
l *(ahc_dump_card_state+0x692)
and give me the output.
Thanks,
Justin
To Unsubscribe: send
>> Can you do a:
>>
>> cd /usr/src/sys/i386/compile/MYKERNEL
>> gdb -k kernel.debug
>> l *(ahc_dump_card_state+0x692)
>>
>> and give me the output.
>>
>
> I'm sorry but i replaced the hd and as it survided the buildworld
> discarded the old one. I still have the compile-director
> System and kernel slice at 1200 GMT 30 Sep 2002 where
> the log showed a whole series of changes to the Adaptec
> drivers: kernel came up, ran for a few minutes, then
> hung.
There have been no major changes to the aic7xxx driver in the last
few days. A few $Id updates, a fix t
> Me neither but my 2642 additionally only boots from channel B.
Meaning it hangs if you attempt to boot from channel B? I really
have no feel for what the actual failure mode is yet. Do we get
timeouts? No devices are seen? What does a verbose boot print out
about the controller and its term
> Hi,
>
> I am running current cvsuped within this week. I have an adaptec
> builtin scsi controller and a seagate drive attached to it and
> after every bootup as soon as there is heavy disk activity
> the drive gets disabled for 1 or 2 minutes and meanwhile all
> functionality RELATED to disk
>> What functionality is lost by this ability?
>
>Compare the features of the ATAPI vs SCSI CD drivers..
This is exactly why I'd like to see this code merged. The hardware
changes too rapidly. The specs change too rapidly but MMC is MMC.
More of us are getting wives we need to take out to dinne
>:stuff to change from their current model. I also think that just as it
>:is too early to optimize to light weight ithread switches (sparc64 is
>:going to optimize all kthread switches, not just ithreads by using a more
>:general
>
>We have very different development models, and different pr
>The API is intended for the stage-2 commit. The stage-1 commit
>is intended to do all the 'hard stuff' in as straightforward
>a manner as possible. The sysctl / option you talk about here
>existed in my patch set 2 and a half weeks ago.
The API and getting it right is more impo
>:I didn't have to read the patch to know that there were concerns and
>:on-going discussion about the API. In this instance, the issues are
>:not large and can be remedied quickly - all the more reason for the
>:discussion to take place before the commit.
>
>Again, bullshit. You should have
>
>:
>:You came to the conclusion that only *your decision* on what was
>:an appropriate proceedure was the one that mattered. That's not
>:the way this project works. You can't act unilaterally. When people
>:ask you to hold off (and they even asked politely!) so discussion
>:can take place, t
>
>
>On Thu, 7 Mar 2002, Justin T. Gibbs wrote:
>
>>
>> The only way it will get delayed that long is if you spend all of your
>> time stomping up and down, writing in all caps, and tell the rest of
>> us that we have to follow the proceedures you thin
>FWIW, Justin and I have been thinking about (for years, actually) doing
>multipath support inside CAM.
Actually, the multipathing support would be in new-bus and CAM would be
one newbus client able to detect redundant paths and register them
accordingly.
The main thing to remember is that there
>BUS_SPACE_MAXSIZE seems to be related to the 'largest xfer you will be allowed
>to do at one time'- which is wrong because MAXPHYS is larger.
If you look at the x86 implementation, BUS_SPACE_MAXSIZE is only
used in the non-GNUC case and is not referenced (I don't think)
by any driver code. Even
>> a single buffer. I never realized that there was such controversy
>> over this value... it was just put in so that I could have something
>> for the non-GNUC case.
>
>Yeah, but, uh, it'll blow up in one's face.
If it gets compiled, I suppose so.
>The question I have is what *should* we b
>> I think it should go away. We should malloc space to hold the segments in
>> the leaf dma tags and base that size on the information in the tag. The
>> segments would only be allocated on the first dma_map_create call on a
>> tag so that intermediate (i.e. non-leaf) tags never have this stuff
On Sep 20, 2014, at 11:06 AM, Konstantin Belousov wrote:
> On Fri, Sep 19, 2014 at 03:27:25PM -0400, John Baldwin wrote:
>> I suspect it was done out of reasons of being overly conservative in
>> interpreting RLIMIT_STACK. I think it is quite surprising behavior
>> though and would rather we make
avg pointed out the rate limiting code in vm_pageout_scan() during discussion
about PR 187594. While it certainly can contribute to the problems discussed
in that PR, a bigger problem is that it can allow the OOM killer to be
triggered even though there is plenty of reclaimable memory available
On Dec 4, 2012, at 6:18 PM, Matthew Jacob wrote:
> On 12/4/2012 1:36 PM, Jeff Roberson wrote:
>> http://people.freebsd.org/~jeff/loadccb.diff
>>
> looks ok for isp. This doesn't do diddly for target mode- do you know off the
> top of your head if it will break anything there?
>
It will. I be
On Jan 23, 2013, at 1:39 PM, Alexander Motin wrote:
> On 23.01.2013 21:51, Jaakko Heinonen wrote:
>> On 2013-01-23, Vitalij Satanivskij wrote:
>>> VS> Jaakko Heinonen wrote:
>>> VS> JH> > I see two possible solutions for the problem.
>>> VS> JH> >
>>> VS> JH> > 1) Replace non-printable, space an
Someone who has yet to confess added -Werror to the global CFLAGS
(via /etc/make.conf) for one of our systems at work. Before I
figured out that this was the cause of builds failing, I hacked up
pam_passwdc to resolve the problem. This gets the module to
WARNS=2, but to go farther, the "logically
>
> I'd have to did some more to see how ashift in cache devices is or isn't
> implemented.
>
> Regards
> Steve
>
> - Original Message - From: "Dmitriy Makarov"
> To: "Steven Hartland"
> Cc: "Borja Marcos" ; ;
&g
On Sep 17, 2013, at 4:53 PM, Steven Hartland wrote:
> - Original Message - From: "Justin T. Gibbs"
>
>
>> Sorry for being slow to chime in on this thread. I live in Boulder, CO and
>> we've had a bit of rain. :-)
>
> Hope all is well yo
On Oct 10, 2013, at 12:40 PM, Michael Schmiedgen wrote:
> Hi List,
>
> is it intended that kernel does not build if
>
> device xenpci
>
> is omitted in the kernel config? I get the following error:
>
> linking kernel
> gnttab.o: In function `gnttab_resume':
> /usr/src/sys/xen/gnttab.c
>
>
>
> Dmitriy Makarov wrote:
> DM> The attached patch by Steven Hartland fixes issue for me too. Thank you!
> DM>
> DM>
> DM> --- Исходное сообщение ---
> DM> От кого: "Steven Hartland" < kill...@multiplay.co.uk >
> DM> Дата: 1
at 4:42 PM, "Justin T. Gibbs" wrote:
> You'll have to be more specific. I don't have that email or know what list
> on which to search.
>
> Thanks,
> Justin
>
> On Oct 16, 2013, at 2:01 AM, Vitalij Satanivskij wrote:
>
>> Hello.
>>
&g
On Aug 8, 2014, at 5:22 AM, Konstantin Belousov wrote:
…
> Below is the patch which adds environment variable LIBPTHREAD_BIGSTACK_MAIN.
> Setting it to any value results in the main thread stack left as is, and
> other threads allocate stack below the area of RLIMIT_STACK. Try it.
> I do not wa
On 6/19/11 6:19 PM, Andrey Chernov wrote:
Exactly that commit is responsible for boot hang.
Please fix.
BTW, I have MBR on SATA disk (CAM emulated), ICH9.
Since it works for me, you'll need to provide more information. Can you
at least drop into kdb to determine the likely source of the hang b
On 6/22/11 4:09 PM, Kenneth D. Merry wrote:
On Wed, Jun 22, 2011 at 08:13:25 +0400, Andrey Chernov wrote:
> On Tue, Jun 21, 2011 at 09:54:04PM -0600, Kenneth D. Merry wrote:
>> These two are interesting:
>>
>>> http://img825.imageshack.us/img825/1249/21062011014m.jpg
>>> http://img839.imageshack
On 6/24/11 3:35 PM, Scott Long wrote:
On Jun 23, 2011, at 11:18 PM, Scott Long wrote:
>
> On Jun 23, 2011, at 9:01 PM, Justin T. Gibbs wrote:
>
>> On 6/22/11 4:09 PM, Kenneth D. Merry wrote:
>>> On Wed, Jun 22, 2011 at 08:13:25 +0400, Andrey Chernov wrote:
>>&g
On 6/24/11 6:26 PM, Andrey Chernov wrote:
On Fri, Jun 24, 2011 at 04:20:24PM -0400, Justin T. Gibbs wrote:
> Instead, I believe that either one of the GEOM taste methods is
leaking an
> access reference (so cdclose() is not called), or the CD driver is
failing
> to release
On 6/25/11 12:39 AM, Andrey Chernov wrote:
On Fri, Jun 24, 2011 at 09:09:08PM -0400, Justin T. Gibbs wrote:
>> No problem. I just set kern.geom.debugflags=4 in loader.conf and here is
>> new photo (with recent kernel, no patches):
>> http://img803.imageshack.us/img803/4679/25
101 - 135 of 135 matches
Mail list logo
