On Wed, Sep 26, 2007 at 06:20:14PM +0200, Michael Reifenberger wrote:
> That issue is fixed.
Just looked at netbsd-iscsi-20070908 and it does look fixed in that
version.
Thanks,
Craig
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org
On Tue, Sep 25, 2007 at 06:19:30PM -0400, Mark Saad wrote:
> Does anyone know off hand if this works in FreeBSD or NetBSD?
The last time (about 1.5 months ago) I tried the iSCSI target from
ports -- net/iscsi-target, it had some issues.
The first was that it didn't work with raw devices. The cau
On Mon, Aug 20, 2007 at 05:35:34PM -0500, Eric F Crist wrote:
> On Aug 20, 2007, at 8:12 AM, Julian D. Seifert wrote:
> >I'm running an ircd (derived from unrealircd) on a FreeBSD 5.5-
> >Release.
>
> At the risk of sounding rude, the 5.x series of FreeBSD is
> deprecated.
FYI, 5.5 is official
On Wed, Aug 08, 2007 at 11:23:25AM -0500, Biks N wrote:
> I am new to FreeBSD kernel programming and I am trying to use userland
> library (zlib) in FreeBSD kernel. But I am not sure if zlib library is
> linkable from the kernel.
Normally, no, you can't just link in a library designed for userland
On Sun, Jul 01, 2007 at 01:26:09AM -0700, Josef Grosch wrote:
> 3) 3ware's new SATA RAID controller (9500)
Latest -stable seems to have this already; at least one that's recent
enough for a shiny new 9650SE to work (which doesn't work in 6.2
release).
Craig
___
On Sat, Jun 02, 2007 at 11:57:19PM +0100, mal content wrote:
> Logging date appears on one, to be read by any external program and
> commands are read by the program from the other.
I can't speak to the blocking semantics, but if you plan to have more
than one process reading at once, FIFOs won't
On Tue, May 22, 2007 at 02:34:02PM -0400, Marcel Moolenaar wrote:
> GPT is not designed to be a sub-partitioning scheme. It can not be
> used within a partition. As such, absolute block addresses are the
> same as relative block addresses. As such, no mistake has been made
> yet.
Ah, that does mak
On Tue, May 22, 2007 at 09:57:34AM +0200, Ivan Voras wrote:
> and that the fields in the GPT are supposed to be disk-absolute (which
> is not a problem on FreeBSD but may be on other systems).
Grrr, this is one design "feature" of BSD disklabels that I was hoping
might finally go away. But it see
On Thu, Apr 12, 2007 at 02:22:31AM +1000, Alan Garfield wrote:
>
> jnet0: port 0xa8,0xae-0xaf irq 19 on acpi0
> jnet0: alloc io port: 00a8 size: 1
> jnet0: alloc io port: 00ae size: 2
> jnet0: Ethernet address: 00:09:3d:00:00:03
>
Looks like it's on the right track, glad I could help!
Ok, well just for the record it's been a while since I've worked with
busdma so my knowledge is more of a high level overview. Hopefully if
I get anything wrong someone will step in and correct me. :)
On Thu, Apr 12, 2007 at 12:37:07AM +1000, Alan Garfield wrote:
> I've got a very machine specifi
On Wed, Apr 11, 2007 at 09:49:17PM +1000, Alan Garfield wrote:
> I've done an acpidump and indeed the are _CRS and _PRS ResourceTemplates
> that describe the io and irq requirements perfectly. How do I access
> this data? ACPI seems to have very little documentation and nothing else
> seems to g
On Wed, Apr 11, 2007 at 09:02:14AM -0500, Craig Boston wrote:
> If it seems like magic, that's because it is. :) For PnP busses like
> PCI, ISAPnP, and ISA-ACPI/LPC-ACPI, the OS takes care of figuring out
> what resources to use and allocates them.
I almost forgot, the busdma func
On Tue, Feb 27, 2007 at 04:12:52PM -0600, Jim C. Nasby wrote:
> On Tue, Feb 27, 2007 at 03:59:52PM -0500, Kris Kennaway wrote:
> >
> > I've mentioned this a couple of times, but postgresql didn't scale
> > well [on freebsd at least] when I tried it last year. I hope to
> > revisit when I get time
On Wed, Jan 10, 2007 at 11:21:01PM -0500, John Nielsen wrote:
> 5) Finally, how dangerous is this code? I realize it's experimental and only
> plan to use it with data that has recent backups, but how much should I
> worry about it blowing up my system or corrupting my files?
Just my personal ex
On Thu, Nov 02, 2006 at 10:52:19AM +, Jan Grant wrote:
> This is, I reckon, the only sensible suggestion thus far: if the FS
> doesn't help you then you are implicitly depending on the FS
> implementation to ensure you are writing over the original data blocks
> anyway.
And you may very wel
On Wed, Jan 25, 2006 at 08:04:07AM -0700, Scott Long wrote:
> Either that, or the read imposes enough delay to let whatever was
> happening during the DELAY call work. I find it hard to believe that
> uncached writes would get delayed like this. I've lost the original
> posting on this, could yo
On Tue, Jan 24, 2006 at 10:43:49AM -0500, John Baldwin wrote:
> What if you do a read of the lapic before the write? Maybe doing 'x =
> lapic->eoi; lapic->eoi = 0;'?
Reading the lapic before the write has no effect.
Reading the lapic after the write makes it work.
Craig
__
On Fri, Jan 20, 2006 at 03:42:21PM -0500, John Baldwin wrote:
> On Thu, Jan 19, 2006 at 10:17:39PM -0700, Scott Long wrote:
> > This points to a bus coherency problem. I wonder if your BIOS is
> > incorrectly setting the memory region of the apics as cachable. You'll
> > want to bug Baldwin about
On Fri, Jan 20, 2006 at 03:42:21PM -0500, John Baldwin wrote:
> Hmm, well, you can actually try the PAT patch if you are feeling brave as it
> maps all devices (including APICs) as uncacheable.
Heh, took me a minute to find. I first found the one at
http://people.freebsd.org/~jhb/patches/pat.pat
On Thu, Jan 19, 2006 at 10:17:39PM -0700, Scott Long wrote:
> This points to a bus coherency problem. I wonder if your BIOS is
> incorrectly setting the memory region of the apics as cachable. You'll
> want to bug Baldwin about this.
I CC-ed him on my post since he was working with me on the pro
After trying everything I could think of to do to the I/O APIC code and
coming up empty, tonight I went back to the local APIC. I had
previously ruled it out since the lapic timer interrupt continued to
work fine even when the others stopped. However, adding some DELAY(1)
calls at key points caus
(bcc to -hackers since it also mostly concludes the "Weird PCI interrupt
delivery problem" thread)
Here's the current status of getting this model laptop to work with
FreeBSD.
Summary
It's possible to get most features working,
On Mon, Dec 05, 2005 at 07:51:29PM -0600, Craig Boston wrote:
> With the ACPI timer disabled (debug.acpi.disabled=timer), the ACPI+APIC
> case now behaves the same as the plain APIC case. Each IRQ gets
> anywhere from 10,000-500,000 interrupts before it simply stops working.
And to fol
On Sat, Dec 03, 2005 at 06:41:31PM -0600, Craig Boston wrote:
> I'll keep hacking on it and follow up here if I figure anything out.
Following up, I have made some interesting progress.
With the ACPI timer disabled (debug.acpi.disabled=timer), the ACPI+APIC
case now behaves the same as t
tus: 5.0.0
Diagnostic-Code: X-mail; host mail.dcc-servers.net[204.152.184.184] said: 550
5.7.1 mail jB41YEJt015277 from 69.55.238.164 rejected by DCC (in reply to
end of DATA command)
Date: Sat, 3 Dec 2005 19:34:12 -0600
From: Craig Boston <[EMAIL PROTECTED]>
To: Sam Leffler <[EMAIL PROT
On Sat, Dec 03, 2005 at 04:30:58PM -0500, John Baldwin wrote:
> That's becuase the dmesg prints out what their current setting was before the
> pci_link driver attached to them. It's basically what the BIOS set them up
> as.
Ah, makes sense.
> Grrr. I'm pretty much out of ideas at this point.
On Fri, Dec 02, 2005 at 08:17:53AM -0500, John Baldwin wrote:
> > Argh, this is driving me up the wall. I had a hunch that it was somehow
> > connected to level-triggered interrupts. That seems to not be the case,
> > as upon closer inspection the SCI interrupt (9) gets reprogrammed to
> > level/
On Fri, Dec 02, 2005 at 08:17:53AM -0500, John Baldwin wrote:
> If an MADT exists we do use the APIC and don't use ATPICs. That's
> normal.
>
> > 2. I "solved" the previous problem by modifying the ASL to assume
> > PIC mode, and then the tunables started working. It was only able
> > to move de
On Thu, Dec 01, 2005 at 07:11:10PM -0700, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Craig Boston <[EMAIL PROTECTED]> writes:
> : I suspect that really old 16-bit PCMCIA cards with non-sharable
> : interrupts wouldn't work, but does NEWC
On Thu, Dec 01, 2005 at 07:31:46PM -0600, Craig Boston wrote:
> If I'm reading the code correctly, it appears that we call _PIC and set
> the interrupt model to APIC, *if an MADT table exists*, regardless if
> we're actually using the I/O APIC or not. This is what initially had
On Thu, Dec 01, 2005 at 01:42:18PM -0500, John Baldwin wrote:
> Yeah, odd, no $PIR. You can get your cbb0 to work though using a tunable in
> the loader. Something like:
>
> hw.pci9.1.INTA.irq=11
That does fix cbb0. With that line, the cardbus works in plain-old-PIC
mode.
I suspect that real
On Wed, Nov 30, 2005 at 10:35:13AM -0500, John Baldwin wrote:
> > With both ACPI & APIC enabled, it only lasts a few seconds.
>
> You didn't have to futz with the routing in this case?
No, I just took the default routing specified by ACPI.
> > With ACPI disabled, the system panics because the mp
Hi,
I'm working on getting this laptop up and running and need some advice
from PCI gurus. I am running into a really odd problem with PCI
interrupts. After a while they simply stop being delivered. ACPI makes
the problem much worse, but it happens eventually without ACPI too.
The system looks
On Tue, Nov 01, 2005 at 11:41:36AM +0100, Pawel Jakub Dawidek wrote:
> I'll be grateful if you could file PR and send me its number. Thanks!
I just submitted version 2 of the patch as bin/88821.
> Thanks a lot! Unfortunately I don't have time to setup test environment
> (I don't use ipv6 at all)
Hi hackers:
Today I had a need to run ggate over an IPv6-only network. I was a
little surprised that it didn't seem to like that, but not discouraged.
So here's a patch that adds IPv6 support for ggated(8) and ggatec(8)
;)
Overview:
* Standardizes on sockaddr_storage for both sockets and addres
Sigh, that's what I get for editing before I finish writing.
On Tue, Aug 02, 2005 at 12:44:45PM -0500, Craig Boston wrote:
> It's a very remote chance yes, but why
...but why take that chance when mkdir works perfectly fine? Chances
are mkdir will be used at some point during the
On Tue, Aug 02, 2005 at 11:47:19AM -0500, [EMAIL PROTECTED] wrote:
> Well these notions have nothing todo with the way it works, but they are
> interesting still. I would imagine a dir could be linked too if somebody
> managed to insert a rc.d script in that was ordered sufficiently early
> enough
On Sun, Apr 03, 2005 at 09:19:19AM -0700, ALeine wrote:
> [EMAIL PROTECTED] wrote:
> There are some people who would want to be able to issue ATA security
> {set,unlock,disable} password and other commands, but have no BIOS user
> interface to change any of the ATA security settings.
Um, wouldn't
At the risk of going further and further off-topic from
freebsd-hackers...
On Tue, Mar 29, 2005 at 02:29:13PM -0800, Bruce A. Mah wrote:
> Sounds like a bad situation there. On our server we use svn+ssh, except
> for a few Windows clients that use https. (BTW our server is running
> 4-STABLE and
On Tue, Mar 29, 2005 at 11:34:11PM +0200, Joerg Sonnenberger wrote:
> That's not true. There are two major problems with subversion, compared
> to CVS:
> - the size of the working copy is doubled (because of the local cache)
> - annotation is linear in the number of revisions (of a file?)
Not tryi
On Tue, Mar 29, 2005 at 01:25:19PM -0800, Bruce A. Mah wrote:
> Well, someone's part-way there with a Subversion mirror of src/. From
> http://www.freebsd.org/support.html:
>
> A public Subversion mirror of the FreeBSD src/ CVS repository is
> provided at svn://svn.clkao.org/freebsd/.
Ah, yes, I
On Tue, Mar 29, 2005 at 05:05:38PM +0200, Divacky Roman wrote:
> wasnt here some discussion about moving FreeBSD to subversion (as some other
> projects did - samba, mono etc.)? and subversion solves this...
Yes, a few people have looked at it from time to time (raises hand as
one of the guilty pa
On Friday 03 December 2004 8:20 am, Stefan Midjich wrote:
> I know a guy i respect on IRC told me this is not possible but since
> this is the hackers list i thought the topic at least deserves a
> discussion. I guess i wont be able to sit still until someone either
> does it or shows me why it can
On Wed, Nov 24, 2004 at 02:36:55AM -0500, Daniel Eischen wrote:
> Tor Egge reported similar problem to me yesterday. I haven't had a chance
> to test his patch, but this supposedly fixes it.
He just sent me the patch via private mail a few minutes ago. With his
patch applied, the stack (after th
First of all, I'd like to apologize for cross-posting to -hackers and
-threads. I'm not sure yet if this is an application bug, a gcc
bug, or a pthreads bug, so here goes...
I'm currently working on the audacity port. It's up to 1.2.3, but I
want to get a problem I've observed with 1.2.2 resolve
Just noticed the forwarded message...
> > From: epilogue <[EMAIL PROTECTED]>
> >
> > i just noticed this driver turn up in the openbsd code. i'm suspecting
> > that it might resolve pc-pda connectivity issues for some users.
> >
> > [snip]
> >
> > would really appreciate it if a committer glanc
Hi,
On Tue, Nov 23, 2004 at 11:09:59AM +0100, Marco van de Voort wrote:
> I'm also in need for a cdce device.
>
> I had the below URL running with 5.2 (and some currents from mid-summer),
> but it fails to compile with 5.3
>
> http://www.gank.org/freebsd/cdce.tar.gz
When did you pull down that
Hi -hackers:
Just wondering if I could get a committer's attention to look at
bin/59883. It seems that m4 has been broken for quite some time -- at
least in the ability to rename builtin macros -- defn() doesn't work
correctly anymore. I've been using the simple patch in the PR locally
for the l
On Sunday 23 May 2004 7:25 pm, Sam Lawrance wrote:
> That would be great, I would love to take a look at it.
I'll go ahead and copy the list in case anybody else is interested...
You can grab the source at
http://www.gank.org/freebsd/cdce.tar.gz
I'm planning to eventually make a FreeBSD projects
Hi,
On Sunday 23 May 2004 8:22 am, Sam Lawrance wrote:
> Do we have generic support for the USB CDC Ethernet class? I can't find
> anything to suggest we do. If not I plan to have a go at writing it.
>
> I just installed linux on my ipaq. It masquerades as an ethernet class
> device in order to co
Unless somebody chimes in and just really wants me to stick this out to the
bitter end, I'm about to kill my attempted import of the FreeBSD src/
repository into a test Subversion instance.
The process has just passed the 1 month mark:
USER PID %CPU %MEM VSZ RSS TT STAT STARTED
On Monday 01 March 2004 10:53 am, Dag-Erling Smørgrav wrote:
> Swen and MyDoom are easy to detect and reject at the SMTP stage. The
> fact that our mail servers don't do this is a PITA, as it forces list
> subscribers to accept them as well (if you reject list mail because it
> contains a virus, M
Just a quick update -- since the individual directories imported ok I decided
to give it a go with the newest (and possibly last before 1.0) subversion,
0.37.0. This time I'm importing the entire src/ repo to see what it can
handle. I'm not quite brave enough to go after ports yet :)
I'm usin
On Monday 09 February 2004 03:06 pm, Stijn Hoop wrote:
> Well, that explains a lot -- for some reason I tested using
> $LastChangedRevision: 7921 $. I'll try with an up-to-date one then.
I was looking through the change history for cvs2svn.py and it seems that the
0.37 version is almost exactly t
On Monday 09 February 2004 11:53 am, Stijn Hoop wrote:
> Did you have to modify the script, or pass unusual options? I'd like to
> reproduce this, but I didn't get very far when I tried a few days ago with
> the 0.37.0 version of the tool.
No, I used the script as-is. The version I have is LastCh
This is a bit of a long email, so please skip unless you're into source code
revision management :)
This is an informal report on the viability of using Subversion to manage the
FreeBSD source code repository. Some of this is generic and will be familiar
to anyone who has looked at SVN before,
On Sunday 09 November 2003 10:34 am, Reinier Kleipool wrote:
> I am investigating the possiblilies for looking at the kernel boot
> parameters from within a userland utility. (Possibly a new FreeBSD install
> facility) The idea is that by looking at sysctl kern.environment.* you
> should be able
This is probably more appropriate on -hackers at this point, so I'm
redirecting there. Bcc current so interested parties know where to look.
I'm also changing my From: to my -hackers address, so don't be alarmed ;)
On Tuesday 23 December 2003 12:52 am, Peter Jeremy wrote:
> I don't recall that.
58 matches
Mail list logo
