Re: iSCSI Target and raw devices
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/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: iSCSI Target and raw devices
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 cause was that in a couple places it tries to read a single byte from the device, but on FreeBSD where everything is a character device you have to read using the block size. I suspect that NetBSD still has buffered block devices so it isn't an issue there. I hacked it locally to read 512 (at mediasize-512 instead of mediasize-1) for its test and that seemed to work, but it was pretty ugly. The right way would be to use an ioctl to get the block size I think. The other thing was that it was listening on a different port number than the FreeBSD initiator was trying to connect to. For some reason even though iscsi-target claims to have a "-p" option to specify the port number, after reading the code it was clear that it doesn't actually use that value for anything and instead is hardcoded to use whatever is in /etc/services. I checked the NetBSD cvs and the same issue existed there. Reading the code gave me the distinct impression that it was incomplete. > The second question what iscsi initiators are out there ? Along time > ago Lucent had iscsi software for FreeBSD 4.x which has initiator > support but this has a restrictive license and does not support anything > newer then 4.9-RELEASE . Does anyone know what else could possibly be > used on 6-STABLE ? I'm not sure about 6-STABLE, though a kernel initiator was added to 7 not too long ago. Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: process freeze (state *inp)
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 officially supported until May 31, 2008. See http://www.freebsd.org/security/#adv Only security fixes would go into the 5.5 release branch, however. If you have to run 5.x I'd recommend 5-STABLE as regular bug fixes can be committed there. Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using userland library in Kernel
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 into the kernel. Some porting is required to deal with the kernel environment -- things such as not having a full C library available, different memory management, etc. In this case however, there is already a zlib implementation in the kernel. IIRC, geom_uzip and the crypto framework both use it. You may want to check out sys/net/zlib.[ch] and see if it can do what you're after. You'll need to make sure to include a dependency on the zlib module and/or add it to your kernel configuration. Good luck, Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Device drivers to be commited.
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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Open FIFO non-blocking but have write() block(?)
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 do what you want. I suspect unix sockets are closer to the behavior you're after. IIRC using them in datagram mode may give you the ability to write whether or not anyone is listening. Otherwise you'll have to do the normal listen, accept, select/poll loop. Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GPT boot loader?
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 make sense. Does the GPT specification actually say absolute block addresses? That would seem to be redundant if the spec also forbids its use inside a partition. I can't seem to find the actual documents for GPT anywhere. > FreeBSD actually creates a GPT with relative addresses, which means > that if we allow it to be used to sub-partition partitions, it would > not have the same problem as the BSD label. I suppose we're being nonstandard either way, so I'll keep my fingers crossed that this continues to be the case :) Thanks for the clarification. Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GPT boot loader?
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 seems the GPT designers made the same mistake :( It's quite annoying to not be able to simply dd a partition without having to fix up the offsets. The GEOM container-like metaphor is very nice but it sucks that the on-disk formats don't match. Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Resources and ACPI
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! > Looking at this all now it's kind of obvious how it works but until you > gave me the break I was neck deep in confusion. Looking back at the thread I see that you're porting a Linux driver, that explains a lot of the confusion. It's been a while since I've worked with the Linux kernel in depth, but I seem to remember that a lot of drivers (especially machine-specific ones) would get the resource directly, e.g. IO port base address, and then do stuff like outb(base_addr + offset, value); value = inb(base_addr + offset); or write to mapped memory directly by constructing a pointer to the address. While doing this is possible in FreeBSD, it's discouraged as the bus_space API tends to make for cleaner code and is also more portable. On architectures with peculiar alignment requirements, or other restrictions (DMA buffers having to be below a particular address comes to mind, or bounce buffers for PAE), the OS will take care of most of the nitty gritty details for you and allow the driver to contain higher-level code. Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Resources and ACPI
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 specific device (eg. it's built into the PRS > controller on the motherboard) so I don't think I have to worry about > machine independence. Machine independence is just a side benefit of using busdma, really it's the standard "FreeBSD driver API" way of doing things. > At the moment I've got the io ports and irq's being hardcoded into the > driver, which seems icky to me. The acpi bus when the device is attached > outputs all the appropriate resources so _something_ knows what they > are. All I want is a way to access them and to know what they are. The question is, do you really need to know what they are? The way it's supposed to work is you do something like this. int rid; rid = i; /* Allocate the i-th IO port resource */ sc->io[i] = bus_alloc_resource_any(dev, SYS_RES_IOPORT, &rid, RF_ACTIVE); /* Get a tag for use with bus_space */ sc->iot[i] = rman_get_bustag(sc->io[i]); /* Get a handle describing the resource */ sc->ioh[i] = rman_get_bushandle(sc->io[i]); bus_alloc_resource_any tells the OS to use the "default" resource allocation, which for a device that's enumerated through ACPI will be the values that you're seeing through acpi. The rman_get_* functions retrieve the tag and handle associated with the resource for use with the bus_space_* functions. AFAIK these are valid until you call bus_release_resource on sc->io[i], at which point they should be discarded. Then to read or write to registers within your IO range, you would do something like this: bus_space_write_1(sc->iot[0], sc->ioh[0], offset, value); /* Write a single byte to (your first IO port) + offset */ value = bus_space_read_2(sc->iot[1], sc->ioh[1], offset); /* Read a word from (your second IO port) + offset */ When you use bus_space_*, you don't need to know the exact starting address of your ports like you would with outb(). You only need to know the offset within the range that your device uses, the API automatically takes care of the rest. Many drivers wrap bus_space_read_* and write_* in a set of macros that automatically fill in the tag and handler, for convenience. If you really want to know the address, for example to print out for debugging messages: start = rman_get_start(sc->io[i]); size = rman_get_size(sc->io[i]); The "io 0x??? - 0x??? irq X" messages that are printed when the device attaches are normally handled by your parent bus, so you normally don't even need to worry about what the actual port base is. For an IRQ you typically call bus_setup_intr() with your resource pointer and handler function. If you need to know the IRQ number for some reason, rman_get_start() should work on that as well. There are lots of examples of using the busdma API in the kernel tree (virtually every driver). Hope this helps, Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Resources and ACPI
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 get resource lists (except fdc_acpi.c and uart_bus_acpi.c which > don't seem to be complete. ACPI_EVALUATE_OBJECT?!?) In general, you're not supposed to. Use bus_alloc_resource and the bus_space_* functions. busdma was introduced in order to make it possible to write device drivers without having to worry about the specifics of resource allocation / access on any given platform. 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. You only need to specify the type (Memory, IO Port, IRQ) that you want and it takes care of whatever needs to be done for the particular architecture and bus your device is attached to. This means that your driver will work regardless if the resources are specified by ACPI, or if in the future if some mad scientist attaches the hardware to the PCI bus on a SPARC64 instead (with only minimal driver changes). Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Resources and ACPI
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 functions work for non-PnP busses like really old ISA cards as well. The only difference is that the user has to specify the resources manually in /boot/device.hints, but there's a standard API for this as well. Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Progress on scaling of FreeBSD on 8 CPU systems
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. > > Let me know if you need help when you get to that point. Keep in mind > that PostgreSQL's out-of-the-box configuration is pretty conservative, > so you won't get good numbers that way. I was kind of wondering that myself, especially as PostgreSQL uses a multi-process model rather than threads. It seems like it would benefit more from optimization of the Sys-V semaphores and shared memory. Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Best practices for using gjournal with gmirror?
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 experience, but I've found the gjournal implementation to be extremely stable. I'm not doing anything terribly unusual with it, but both my laptop and my primary workstation use gjournal for all of their filesystems except / and /tmp. On my workstation one of the journaled filesystems (/home) is on a mirror using the ataraid(4) driver, but I've also successfully used it with gmirror. I do a lot of parallel source code extraction and building and have never run into a crash or panic that was caused by gjournal itself. The panics and deadlocks I have encountered due to other reasons have shown that using gjournal has actually significantly reduced the amount of FS corruption in those events. You still lose anything created or changed in the last ~30 seconds or so, but that's better than a corrupted FS. I would still be religious about backups just in case, but it's unlikely that gjournal will be the reason you have to use them. Craig * NOTE: I'm running the gjournal backport to RELENG_6. YMMV if running -CURRENT. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] rm can have undesired side-effects
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 well not be. If the underlying FS is say for example journaled or snapshotted, your new data blocks may go to a completely different part of the disk. For UFS today -P may work most of the time, assuming no snapshots or other events moving the file. With gjournal and gvirtstor coming who knows if that will remain true. That doesn't even take into account things like unionfs or other VFS stacking. If writing zeros or whatever to a file (that may or may not overwrite the previous contents on disk) is really what you want to do, dd works just fine for the task. /me votes for removing the -P misfeature altogether Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird PCI interrupt delivery problem (resolution, sort of)
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 you provide the dmesg and computer make/model > again? It's a Toshiba Satellite L25-S1192. The chipset is ATI Radeon Xpress 200M (RS480). Verbose dmesgs are up at http://www.gank.org/freebsd/l25 acpi+apic.txt is a 6.0-RELEASE GENERIC kernel (before I upgraded the memory, but the APIC thing is independent of that) apic2.txt is a verbose dmesg with my current kernel (stock 6.0-STABLE + read-after-write change to local_apic.c). Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird PCI interrupt delivery problem (resolution, sort of)
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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird PCI interrupt delivery problem (resolution, sort of)
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 this.
>
> Hmm, well, you can actually try the PAT patch if you are feeling brave as it
> maps all devices (including APICs) as uncacheable.
Tried the updated PAT patch (with s/pmap_unmapbios/pmap_unmap_bios/ to
get ACPI to compile). Unfortunately if it is a caching problem, PAT
isn't able to fix it. Same result as stock kernel -- interrupts stop
arriving after a dozen or so. AFAICT the local APIC is the only
memory-mapped I/O region that seems to be problematic.
Instead of writing the value twice, I also tried inserting an
__asm("nop") before the write with no effect. Also, a single write to
an unrelated area doesn't help:
+static volatile int dummyeoi;
+
lapic_eoi(void)
{
+ dummyeoi = 1;
lapic->eoi = 0;
+ dummyeoi = 2;
}
I'm _reasonably_ certain that marking dummyeoi volatile and leaving it
uninitialized will prevent gcc from optimizng that out. Forcing R/W
cycles (++dummyeoi) before and after doesn't work either.
A DELAY(1) before the lapic->eoi write does the trick, but DELAY does
lots of complicated things so I don't know how useful of a data point
that is.
I'm probably missing something, but if bad cache behavior was causing
writes to the lapic EOI register to not always take effect, wouldn't the
_next_ irq (even if it's a different line) cause the one that's
currently pending to be acknowledged?
Craig
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird PCI interrupt delivery problem (resolution, sort of)
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.patch but it maps devices as write-back. I'm guessing you mean to use the version in perforce? I'll give it a try tonight. Could hardy make things worse -- I just noticed that X now randomly locks up hard, ever since I bumped up the memory from 256Mb to 2G -- though text mode still works fine. (yes, I tried reverting all my local patches and testing the memory) Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird PCI interrupt delivery problem (resolution, sort of)
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 problem before. For some reason the Cc: header got wiped out when it went to the list (but I checked my server logs and it did deliver a copy of the message to him). Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Weird PCI interrupt delivery problem (resolution, sort of)
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 caused it to work, much like adding WITNESS does.
I managed to get it down to a single change that makes APIC mode work on
this laptop:
--- local_apic.c.orig Thu Jan 19 18:32:37 2006
+++ local_apic.cThu Jan 19 18:32:28 2006
@@ -599,4 +599,5 @@
lapic_eoi(void)
{
lapic->eoi = 0;
+ lapic->eoi = 0;
}
...and welcome to bizarro world. There's absolutely no reason I can
think of why that would change anything, other than buggy hardware.
I looked at what Linux was doing, and they're also using a single write
to EOI interrupts, so long as the X86_GOOD_APIC config option is enabled
(and it is for P5/MMX or newer). Otherwise it does an extra read before
writing to any APIC register. I don't know if linux works on this
hardware or not -- the live CD I tried wasn't compiled for APIC support.
At this point, since AFAIK nobody else has reported the same problem,
I'm content with a local workaround. It's just... wierd.
Craig
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Toshiba Satellite L25 followup
(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, but takes some effort.
I'd not recommend buying one of these to anyone who doesn't want to
get their hands dirty with kernel patches and other workarounds.
The same warning may apply to other ATI IXP400 chipset based
machines as well.
ACPI __
Works, sort of. ASL is in pretty bad shape. Patch is attached that
fixes the battery status and interrupt routing. More details on
interrupt routing at the bottom of this message. Suspend is still
broken -- it suspends but isn't able to wake up.
APIC ___
Broken. Also, the MP Table is broken so it won't even boot without
either ACPI or kernel workarounds. Always use
hint.apic.0.disabled=1 for now.
Sound __
Works. I had started reverse engineering the chip using the windows
driver in a modified qemu. Was half done (ac97 interface and mixer
worked, DMA transfers partially working), when I discovered that
Ariff had beaten me to the punch and committed a driver to current a
few days ago :)
Ariff, I'm CC-ing you as well because there is still a small issue
with the mixer. This particular ac97 codec seems to support the
mute bit of AC97_MIX_BEEP, but no volume levels other than 0 (max).
As a result, it gets muted and marked as disabled so there is no way
to re-enable the PC speaker. Interestingly, the default value of
the register seems to be 0x8000 even though the speaker is _NOT_
muted at bootup.
I've got a local hack to work around it, but it's not a general
solution. The codec ID is 0x43585430.
SMBus __
Doesn't seem to be a driver yet. Can get temperature through ACPI
so this may not be an issue.
Modem __
No driver. Apparently based on the Conexant AC97 codec as well
(i.e. Winmodem). I've seen references to Linux folks working on
this, so it may be possible to get it working, but I haven't tried
yet.
Video __
2D acceleration via the linux drivers (see my original post at
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=155785+0+archive/2005/freebsd-mobile/20051127.freebsd-mobile
for instructions). xorg-server-snap should eventually support this,
but it just segfaults for me.
Here's the rundown for the whole interrupt thread:
APIC ___
The APIC is busted; I'm not sure why. Something is causing it to
start ignoring certain pins after a while. The ACPI and i8254
timecounters exacerbate whatever it is that's causing it to fail.
Running with WITNESS, the APIC seems to work ok. My current theory
is that some register is being updated faster than the hardware can
handle, and WITNESS slows things down enough to not trigger it.
Windows may have additional delays or timing differences in how it
accesses the hardware so it was never noticed during testing.
!APIC (dual 8259A PIC) _
Without ACPI, Cardbus doesn't generate interrupts. Thanks to jhb's
very informative post to stable the other day, I'm certain that it's
because the BIOS isn't setting up the link device that is connected
to it. There is no $PIR table, so although we can try to map an
interrupt to it, we can't program the link device to route it
anywhere.
With ACPI, the _PRT provided for the secondary PCI bus is completely
wrong. After much trial and error I've finally figured out which
PCI link is connected to which slot/pin. The attached patch to the
ASL is able to get everything routed correctly for the +ACPI -APIC
case. Running without the APIC isn't quite optimal, but at least
everything works.
I hope that all this is helpful to any others who have one of these
machines. I'll be attempting to contact Toshiba about these issues and
see if we can't get some of them addressed in a future BIOS update.
Craig
--- toshiba.asl Sat Nov 26 14:37:24 2005
+++ fixed2.asl Wed Dec 7 17:26:59 2005
@@ -192,6 +192,8 @@
Notify (\_SB.BAT1, 0x81)
}
}
+
+ Return (0x0)
}
Scope (\_SI)
@@ -1023,408 +1025,6 @@
Z00A, 32
}
-Device (PB2)
-{
-Name (_ADR, 0x0002)
-
Re: Weird PCI interrupt delivery problem
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 follow up to myself yet again, the i8254 timecounter is also bad news for APIC. Switching to it, with or without ACPI, causes things to stop working really fast. Just a stab in the dark, but it sounds like there may be something screwy going on in the interconnect between the I/O APIC and the 8259s. I'm pretty familiar with old-style (ISA) design, but somewhat fuzzy on exactly how those two normally coexist, especially when everything is integrated together on a bridge chip somewhere. IIRC there used to be some mixed-mode hacks that have been cleaned up in 6.0. Might Windows still be doing something similar and that's why it works? Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird PCI interrupt delivery problem
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 the plain APIC case. Each IRQ gets anywhere from 10,000-500,000 interrupts before it simply stops working. Switching the timecounter from ACPI-fast to something else after boot also improves the situation, but not as much as disabling the timer entirely. Up to about 50,000 but better than the <50 it would get otherwise. Switching the timecounter does not bring back any IRQs that have already "died". Disabling the timer does not change the +ACPI -APIC case, but I've been experimenting with that mode of operation and discovered it's not quite as it fist appeared. It's difficult to tell which device is producing interrupts since they all go to IRQ 11. I didn't notice before, but with +ACPI -APIC, the USB controller works fine (indefinitely). Also, I'm not 100% sure, but I don't think the devices on pci9 are producing _ANY_ interrupts at all. With the APIC enabled, rl0 sometimes lasts long enough to get a lease, but with it disabled it has yet to manage that. Also, the irq 11 count looks too low for multiple devices. I compared the entire PCI configuration space for the bridge with ACPI enabled and disabled and they were identical. The only thing that struck me as suspect is that the secondary status register for the bridge has the received master abort bit set, however that happens even when things are working so I'm not sure it's relevant. I get the same results after "fixing" the _PRT for bus 9. I tried both hardcoding the interrupts to 0xb and routing them via various link devices -- no luck. That's all really academic; I suspect ACPI+APIC is the only configuration that has a chance of actually working, and I'm halfway there... Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird PCI interrupt delivery problem
Sam, I hope you're reading -hackers, it seems errno.com is rejecting my mail again... Forward and reverse DNS looks OK, and I always send from the address published in my SPF records; not sure why it doesn't like me. Final-Recipient: rfc822; [EMAIL PROTECTED] Action: failed Status: 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 PROTECTED]> Subject: Re: Weird PCI interrupt delivery problem On Sat, Dec 03, 2005 at 04:48:20PM -0800, Sam Leffler wrote: > Yes that is too high. Run athstats 1 to see what the interrupts are > for. dmesg|grep ath to identify the part might also help explain things. Haven't been too worried about it yet, just counting my blessings that the "Built-in 802.11g" turned out to be a working Atheros card. Here's the info: ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413) ath0: mem 0xd020-0xd020 irq 11 at device 4.0 on pci9 ath0: Ethernet address: 00:11:f5:89:75:d4 ath0: mac 7.8 phy 4.5 radio 5.6 # ./athstats 1 input output altrate shortlong xretry crcerr crypt phyerr rssi rate 57 1 0 140 11 32394 0 91648 31 54M 00 0 0 0 0207 0 969 31 54M 00 0 0 0 0684 0 523 31 54M 00 0 0 0 0401 0 859 31 54M 00 0 0 0 0476 0 708 31 54M 00 0 0 0 0389 0 841 30 54M 00 0 0 0 0312 0 890 31 54M 00 0 0 0 0751 0 525 31 54M 00 0 0 0 0497 0 757 31 54M 00 0 0 0 0248 0 946 31 54M 00 0 0 0 0864 0 482 31 54M 00 0 0 0 0714 0 579 31 54M 00 0 0 0 0391 0 861 31 54M 00 0 0 0 0373 0 886 31 54M 00 0 0 0 0221 01077 31 54M 00 0 0 0 0736 0 530 31 54M 00 0 0 0 0554 0 666 31 54M 00 0 0 0 0432 0 879 31 54M 00 0 0 0 0220 01070 28 54M - End forwarded message - ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird PCI interrupt delivery problem
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. Yeah, it's pretty frustrating... Then again I knew when I got this machine what I might be getting myself into. Thanks for taking the time to help work on this and provide some ideas. I'll keep hacking on it and follow up here if I figure anything out. > At least you have it working in -ACPI -APIC mode. :-/ Unfortunately it seems that it's actually still broken in this case. I just discovered that even with the hint, the cardbus controller / devices don't generate any interrupts at all. The only reason it seemed to be working is that when I have the radio enabled, ath0 generates about 1000 interrupts/second (which seems high, but that's another discussion). So effectively is was just running in polling mode. I didn't notice that until this morning when I booted into single user mode and was trying to use some cardbus cards before ath0 was configured. Random tangent, it's kind of sad that one of the co-authors of the ACPI spec (Toshiba) would sell a machine that has so many problems with it. Though I think ATI deserves at least part of the blame as this appears to use one of their "system-on-a-chip" designs. Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird PCI interrupt delivery problem
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/low. I can read the ACPI status all day long and the count for > > IRQ 9 goes up and up without freezing... > > Interesting. How about IRQ 11 in non-APIC mode, is it programmed to > level/low? I've seen BIOSes that do very stupid things like have the link > devices set to level/hi or edge/lo or even edge/hi. A verbose boot should > tell you if any settings are changed though, and in the APIC case you should > see the initial defaults as well. Added some printfs to i386/isa/atpic.c. At bootup, everything is programmed by the BIOS to edge/high, except IRQ 11 which is set to level/low. FreeBSD doesn't seem to be changing that as far as I can tell. (this is -APIC -ACPI) Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird PCI interrupt delivery problem
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 devices on the "near" side of the bridge (i.e. on pci0), but > > they did work briefly on IRQ 10 before freezing just as before. > > You shouldn't have to do that. The ACPI standard clearly states that > machines boot up in PIC mode by default and you only need to call _PIC > to switch to either APIC or SAPIC (ia64) mode. Yeah, that was my bad. I misread apic_register_enumerator as acpi_register_enumerator. After tracing it down I see that the MADT check is called after the check for hint.apic.0.disabled. > Did you disable APIC before trying the tunables BTW? Yes, however the first time I only tried tunables for LNKA, B, and C (was typing them by hand). Later I tried with loader.conf and set all 8. Another odd thing is that the dmesg lines for the LNK objects still report irq 11, though the devices themselves do attach to 10. > Interesting. How about IRQ 11 in non-APIC mode, is it programmed to > level/low? If it's not mentioned in verbose dmesg, how do I tell what it's programmed to? Is there already some way to do it that's easier than writing something to read the PIC registers? > hw.pci9.1.INTA.irq=11 > Also, try this hint with ACPI without APIC. It looks like your BIOS doesn't > include entries for the PCI9 bus in the PIC version of the _PRT (see no PRT > messages in ACPI dmesg) so cbb0 doesn't get an IRQ there either. The hint "works" with ACPI, in that cbb0 attaches. However by the time I'm able to insert a card, irq 11 has already died so nothing happens. Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird PCI interrupt delivery problem
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 NEWCARD even support those anyway? > > Yes. There's no such thing as a PCMCIA card whose interrupts are > non-sharable. NEWCARD works great with them. Heh, guess I shouldn't believe what I read on pages hosted at microsoft.com :) http://www.microsoft.com/whdc/system/bus/cardbus/PCMCIA-IRQrouting.mspx (found via google search for "cardbus interrupt routing") It's probably talking about legacy device drivers that didn't know how to properly share IRQs. Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird PCI interrupt delivery problem
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 me > thinking ACPI/PIC wasn't supported at all. No, scratch that, the enumerator never gets called unless a local apic device attaches. The code is correct. Bizarre, I wonder why the tunable to override LNK[A-H] wasn't working before. Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird PCI interrupt delivery problem
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 really old 16-bit PCMCIA cards with non-sharable interrupts wouldn't work, but does NEWCARD even support those anyway? > should do the trick to get your box working in the !ACPI and !APIC case at > least and you can see if it has the same issue with freezing up then. So far it seems to be working fine with !ACPI !APIC and that tunable. I'm pingflooding some "volunteers" on the wired and wireless LANs, and transferring 16MB/s from an external drive over firewire (cardbus fwohci). So far it's been running for about 30 minutes with a sustained interrupt rate of ~6000. That would be more than enough to kill it in the plain APIC (no ACPI) case. Still, this thing doesn't have apm so if I want any sort of power management I'll need to figure out why ACPI & APIC are broken. > For a test, you can try compiling cbb out of your kernel and seeing if > the box works ok. No luck, still fails exactly the same in ACPI mode with cbb removed from the kernel. > That's cbb0 and it has no address assigned to BAR 0x10 (nor an IRQ). Unfortunately the BIOS is no help here either -- the only thing configurable is the boot order... > I'd still be interested to hear how the broken kernels fair if you > take cbb out and how the 8259 kernel does with the variable set to fix > cbb0's interrupt. All 3 (broken) combinations of ACPI and APIC behave exactly the same with cbb/pccard/cardbus removed from the kernel. :( > You could also try moving one of the links to IRQ 10 in the ACPI case > via a tunable such as: > hw.acpi.LNKA.irq=10 or some such (can't recall if that's the right > name). Looks like it's hw.pci.link.LNKA.irq. However, there are a couple problems: 1. The ASL for this machine expects to be notified of the interrupt model via the _PIC method. It changes the _PRT depending on which model is in use. For APIC, it doesn't use the PCI link objects at all and just hardcodes all the vectors. For PIC, it uses the LNK objects (which are constrained to IRQ 10 or 11). 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 me thinking ACPI/PIC wasn't supported at all. 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 devices on the "near" side of the bridge (i.e. on pci0), but they did work briefly on IRQ 10 before freezing just as before. I think this is unrelated to my problem, however, as I get the same behavior both with and without that modification (but it may be a bug that needs to be fixed). 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/low. I can read the ACPI status all day long and the count for IRQ 9 goes up and up without freezing... Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird PCI interrupt delivery problem
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 mptable is broken. > > However, I was able to hack the kernel to override the mptable and > > route the interrupts to the correct pins. > > You know that you can override individual routings just using tunables > without having to hack the table. Just use something like: Oh yeah, thanks, I forgot about that. Though I think I would have to hack the table anyway just to get the system booted -- it panics due to the bogus entries long before it tries to route any INTs. > hw.pci0.2.INTA.irq=17 to route pci bus 0, slot 2, pin A# to IRQ 17 > (apic 0, intpin 17). Determining the correct intpins can be tricky > though. I studied the _PRT entries in the DSDT and compared with what Windows was using to figure out where they should go, I'm 99% sure it's correct. > The code does not assume APIC at all. What does an unmolested kernel > actually do with ACPI enabled but APIC disabled? Whoops, you're right. The first time I tried that I must have made a typo in the hint to disable the APIC because it "ignored" me and used it anyway. Then I read sys/i386/acpica/madt.c to mean that if an MADT table is present it flips on APIC mode unconditionally. A GENERIC kernel with ACPI but no APIC does the same thing, however. Everything ends up on IRQ 11 and it does just that much quicker. vmstat -i shows IRQ 11 frozen at 55 interrupts (the number varies per boot). > > The final thing I tried is both APIC & ACPI disabled > > Do you have a dmesg from this? Preferably a verbose one to see if > your $PIR has routing info for cbb0. Yes, I have verbose dmesgs up at http://www.gank.org/freebsd/l25/ (I've been running RELENG_6, but reverted to a 6.0 GENERIC to create these as to rule out any local patches) 8259.txt is the one with both APIC & ACPI disabled. I don't see a $PIR table anywhere though -- I don't think this board was intended to be run without ACPI... > We mask the IRQs in the PIC while their ithread runs. If your routing > is all screwed up that might result in the problems you are seeing. > Can you boot into Windows and jot down the IRQs it uses for each > device I'm pretty sure the routing is OK, but am game to try anything that might help. I don't have Windows on this machine anymore, so I called a friend with an identical laptop and had him go through device manager. Highlights include USB on IRQ 19, the integrated RealTek NIC on IRQ 21, and the MiniPCI wireless on IRQ 22. It matched exactly with with the IRQ lines that BSD uses with APIC, with or without ACPI. > and then (if you are up to it), provide verbose dmesg's of an > unpatched kernel for the 4 cases of + ACPI + APIC, - ACPI + APIC, + > ACPI - APIC, - ACPI - APIC? Sure, see the link above. The files are: 8259.txt- ACPI - APIC acpi+apic.txt + ACPI + APIC acpi.txt+ ACPI - APIC I couldn't get one for - ACPI + APIC as it panics on bootup and this machine doesn't have a serial port. I did post a verbose boot with my patched kernel for that under apic+patches.txt. Also in there is mptable.txt, which shows the broken mptable. mptable-fixed.txt is the output of the mptable command when running with a patched kernel in APIC (no ACPI) mode. Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Weird PCI interrupt delivery problem
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 like this: pcib0 pci0 ohci0 pcib2 pci9 cbb0 rl0 ath0 However, the problem affects ohci0 as well so I don't think the PCI bridge is the culprit. Actually, the only PCI device in the system that doesn't seem to be affected is the ATA controller, and I think that's because it uses ISA interrupts 14-15. With both ACPI & APIC enabled, it only lasts a few seconds. Each pin on the I/O APIC manages about 10-50 interrupts before they simply stop coming. The number of interrupts seems to be the deciding factor rather than time -- I can wait a minute and ohci0 will work until I move a USB mouse around for a while. With ACPI disabled, the system panics because the mptable is broken. However, I was able to hack the kernel to override the mptable and route the interrupts to the correct pins (actually it rewrites parts of the mptable as it's being parsed). In this configuration, everything works fine for a while, but it eventually dies. ath0 is usually the first to go since it generates a steady stream of interrupts, but given enough time they eventually all stop. Sometimes it happens after 50,000 sometimes 500,000. I also tried ACPI enabled but APIC disabled. The FreeBSD ACPI code seems to assume APIC interrupt model for i386, so it took some modifications to get this working. Everything ends up on IRQ 11, though I'm not sure if it's getting reprogrammed to be level triggered or not. Symptoms are the same as with APIC on -- after 10-50 interrupts it just stops. The final thing I tried is both APIC & ACPI disabled -- route everything through the 8259. In this mode, cbb0 fails to attach (Unable to map IRQ). Everything else ends up on IRQ 11, however it does seem to work indefinitely. Oh, when APIC is being used, vmstat -i reports the lapic timer interrupt happily churning away without problem. I've checked everything I can think of -- no reports of interrupt storms, everything looks normal in verbose boot. I was just going to run in PIC mode until I discovered that cardbus didn't work. Any ideas on things to try to debug this? First thing that comes to mind is to see if the IRQ is being intentionally masked for some reason, but I can't think of an easy way to check that. Thanks, Craig P.S. Yes, it does sound like a wonky PCI bus, but stock XP runs with ACPI & APIC with no problems. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] IPv6 support for ggate
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) and it can take a while before I'll be ready > for committing this (if noone else beat me on this). No problem, I can very much identify with not having enough time. I'm no stranger to maintaining local patches, so no hurry. For anyone following along who wants to try this out, grab the patch from the PR rather than the one I posted earlier. Please test even if you don't use IPv6 to make sure everything still works. The new patch has several improvements over the first one: * Much cleaner in a few places (notably mask handling & address binding) * ggated now allows binding to an arbitrary number of local addresses, just specify -a for each one you want to use * Eliminates most cases of conditional code on AF_*. The only ones left deal with network masks for access control that can't really be generalized Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[PATCH] IPv6 support for ggate
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 addresses
* A few semantic differences for certain functions due to the above
change (ip2str, g_gate_str2ip)
* ggated by default listens on both v4 and v6 sockets (uses select loop
instead of accept loop). You can listen on v4 only with "-a 0.0.0.0"
or v6 only with "-a ::", or of course bind to a specific address
* Use getaddrinfo in place of gethostbyname, and parse addresses with
inet_pton
* All address are stored internally in network byte order now. Mask
comparisons should be independent of byte order since it's purely a
"vertical" comparison.
Things I'm not entirely happy with:
* More AF_INET/AF_INET6 conditional code than I'd have liked to add.
Unfortunately there doesn't seem to be an easy way to be protocol
neutral with a lot of the socket functions.
* The v6 part of countmask is really ugly and complicated. I need to
check the ifconfig source and see if there's any standard way for
converting a /nnn mask to a binary mask.
* When resolving DNS names, it will only use the first entry if there
are multiple. It technically always had this problem, but it's more
noticeable now. Networks are more likely to have names with both a v4
and v6 record than to have multiple v4 addresses. Fixing this the
'right way' would require significantly more invasive changes.
Other than that, I was running with this patch for most of the afternoon
with great success. Now I just need to write a kernel mode ggatec so I
can mount root over ggate :P
-- Craig
diff -ruN ggate.orig/ggatec/ggatec.c ggate/ggatec/ggatec.c
--- ggate.orig/ggatec/ggatec.c Thu Oct 27 22:12:19 2005
+++ ggate/ggatec/ggatec.c Thu Oct 27 22:28:22 2005
@@ -244,21 +244,27 @@
struct g_gate_version ver;
struct g_gate_cinit cinit;
struct g_gate_sinit sinit;
- struct sockaddr_in serv;
+ struct sockaddr_storage serv;
int sfd;
/*
* Do the network stuff.
*/
bzero(&serv, sizeof(serv));
- serv.sin_family = AF_INET;
- serv.sin_addr.s_addr = g_gate_str2ip(host);
- if (serv.sin_addr.s_addr == INADDR_NONE) {
- g_gate_log(LOG_DEBUG, "Invalid IP/host name: %s.", host);
- return (-1);
+ serv = g_gate_str2ip(host);
+ switch(serv.ss_family) {
+ case AF_INET:
+ ((struct sockaddr_in*)&serv)->sin_port = htons(port);
+ break;
+ case AF_INET6:
+ ((struct sockaddr_in6*)&serv)->sin6_port = htons(port);
+ break;
+ default:
+ g_gate_log(LOG_DEBUG,
+ "Invalid IP/host name: %s.", host);
+ return (-1);
}
- serv.sin_port = htons(port);
- sfd = socket(AF_INET, SOCK_STREAM, 0);
+ sfd = socket(serv.ss_family, SOCK_STREAM, 0);
if (sfd == -1) {
g_gate_log(LOG_DEBUG, "Cannot open socket: %s.",
strerror(errno));
@@ -267,7 +273,7 @@
g_gate_socket_settings(sfd);
- if (connect(sfd, (struct sockaddr *)&serv, sizeof(serv)) == -1) {
+ if (connect(sfd, (struct sockaddr *)&serv, serv.ss_len) == -1) {
g_gate_log(LOG_DEBUG, "Cannot connect to server: %s.",
strerror(errno));
close(sfd);
diff -ruN ggate.orig/ggated/ggated.c ggate/ggated/ggated.c
--- ggate.orig/ggated/ggated.c Thu Oct 27 22:12:19 2005
+++ ggate/ggated/ggated.c Thu Oct 27 22:37:55 2005
@@ -68,7 +68,7 @@
time_t c_birthtime;
char*c_path;
uint64_t c_token;
- in_addr_tc_srcip;
+ struct sockaddr_storage c_srcaddr;
LIST_ENTRY(ggd_connection) c_next;
};
@@ -84,15 +84,16 @@
struct ggd_export {
char*e_path;/* path to device/file */
- in_addr_te_ip; /* remote IP address */
- in_addr_te_mask;/* IP mask */
+ struct sockaddr_storage e_addr;/* remote IP address */
+ struct sockaddr_storage e_mask;/* IP mask */
+ unsigned e_prefixlen;
unsigned e_flags; /* flags (RO/RW) */
SLIST_ENTRY(ggd_export) e_next;
};
static const char *exports_file = GGATED_EXPORT_FILE;
static int got_sighup = 0;
-in_addr_t bindaddr;
+struct sockaddr_storage bindaddr;
static TAILQ_HEAD(, ggd_request) inqueue = TAILQ_HEAD_INITIALIZER(inqueue);
static TAILQ_HEAD(, ggd_request) outqueue = TAILQ_HEAD_INITIALIZER(outqueue);
@@ -116,31 +117,71 @@
}
static char *
-ip2str(in_addr_t ip)
+ip2str(struct sockaddr *addr)
{
-
Re: [patch] rc.d/tmp (silly mkdir usage)
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 rc.d startup anyway, so forking a process for an executable in the cache (or bringing it into the cache so it can be used later) is a negligible performance loss, especially when it only happens once. Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] rc.d/tmp (silly mkdir usage)
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 to do the evil tasks you are thinking about. Even if mktemp(1) were > available at this stage, I wouldn't use it here. A link could also be left over from before the boot. rc.d/tmp runs before cleartmp. > Let me be clear about this, the ONLY reason mkdir is used here is > because touch is under /usr somewhere which isn't even mounted at this > point (assuming /usr is mounted seperatly, as is the case on nfs > diskless systems). No, touch has different behavior than mkdir. Whether it was done intentionally or just happens to be the case because /usr is not available, mkdir is the most secure and robust way to go, because it covers all of the cases: 1) /tmp/.diskless doesn't exist -> A directory .diskless is created, which is then removed 2) /tmp/.diskless is a link to a file -> mkdir fails because "File exists" 3) /tmp/.diskless is a link to a directory -> mkdir succeeds but does nothing because -p was specified. The link is then removed. 4) /tmp/.diskless is a link to a nonexistent path or name -> mkdir fails (even with -p) because it can't follow the link: "No such file or directory" 5) /tmp/.diskless exists and is a file -> mkdir fails: "File exists" 6) /tmp/.diskless exists and is a directory -> mkdir succeeds. Later, /tmp/.diskless is removed _only_ if it is empty. Even though touch doesn't change file contents, it could potentially be abused to change the timestamp on an arbitrary file if a link were left in /tmp. The only way to securely use touch or ">" would be to rm -f /tmp/.diskless first, and that is a potentially destructive operation on the off chance the administrator created a file called /tmp/.diskless. It's a very remote chance yes, but why Creating a file called that may cause undesired effects such as mounting an mfs /tmp when you didn't want one, but it won't cause any data loss. > So we are left with what is availabile in /bin, /sbin, /rescue. > Therefore mkdir was used as a work-around. What I'm saying is this > entire thought process is overly-engineered when the shell can simply > "touch" a file with stdout or stderr. This is indeed the most minor of > optimizations. It's not a minor optimization if it changes the semantics of what happens. > is very dangerous because it could nuke a random file if a symlink exists. Even >> or touch can mess with timestamps or create files that don't exist, all with the power of root. Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA security commands, bug in atacontrol
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 setting the password on a system in which the BIOS offers
no ATA security support render the system unbootable? The BIOS would
be unable to read the boot sector without first unlocking the disk...
Since compliant BIOSes have already frozen the config by the time the OS
boots anyway, the only reason I can think of for atacontrol to have
security support would be if you're booting from some other media, i.e.
floppy, CDROM, network, USB...
It might also be somewhat useful for secondary (non-boot drives). *BUT*
that would probably only work on machines where the BIOS doesn't freeze
all the drives on startup.
Craig
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: organization
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 it's wonderful.) Hmmm, I initially didn't want to use that because I read that it suffers from the same security issues as CVS. The appeal of being able to fine-tune permissions and grant subversion access without shell access is quite luring. HTTP timeouts during long operations, on the other hand, suck. ( my server is woefully underpowered :-D ). Note to davsvn users with slow servers: http-timeout = 3600 is your friend. > Heh. :-) 1.1.3 is current now, but one can find mentions of a 1.1.4 > bugfix release being planned, as well as the (farther out) 1.2 release > with locking. Oh, I've been running 1.1.3 on both client and server since it went into ports (many dump/loads later). Just haven't taken the time to see what's new and compare to older versions. :) Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: organization
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 trying to spread false information about Subversion -- I like it very much and use it for all my personal projects :) Just stating my opinion based on observations made while using it. > The first can be work-arounded by using SVK, but often is also an > advantage, because e.g. diff is a pure local operation which doesn't > have to contact the server. Well, you don't have the extra working copy files, but you usually end up eating up at least as much space for your local repository mirror; unless you have a lot of working copies checked out. > On the other hand, CVS definitely doesn't scale to large repositories too, > just think about the time a "cvs up" or "cvs tag" needs. You can't make > everything fast, it is a compromise between speed, disk space and not to > forget atomarity. Keeping in mind that the tests I ran were back in the pre-1.0 days (right before 1.0 IIRC), Subversion was much faster on update, but significantly slower for checkout and diffs. Those operations scaled worse than O(n) as the repository grew. It would be interesting to run some more benchmarks (clkao's mirror eliminates much of the import hassle) and see how the latest subversion compares. Also, as Bruce reminded me, the new fsfs storage backend may have different characteristics that need to be taken into account. Of course Subversion fares much better on the atomicity issue, that's a given :) svk may be able to help too. I tried it for a while but eventually gave up because getting the perl bindings installed and working was a bit of a black art. Probably time to try the port again. Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: organization
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 do remember Chia-liang Kao was working on a CVS <->
Subversion bridge for use with svk. The ability to do incremental
updates, even if it's only one-way, is a big win on both sides of the
fence.
> This of course doesn't include ports/ or doc/, so it doesn't really
> answer the scalability question.
Most of what I ran into was just in src/. I hesitate to say anything
since it's been a long time and my memory is vague. ISTR a few simple
operations on a file at the top level were causing the entire tree to be
traversed. Unfortunately I don't remember exactly -- maybe it's time to
test it again...
One issue I do remember had to more do with apache and davsvn rather
than subversion itself. Attempting to cancel a long running operation
(say an accidental svn diff of the whole tree) would kill the frontend
but leave the backend churning away on the server, which would bog down
further requests (locking?), causing them to hang for a while, build up
requests, and make the situation worse.
I use subversion exclusively for my personal projects but none are big
enough that I've run into that problem again. It may well have been
fixed by now -- the version number has been creeping up while I wasn't
looking :)
> This is dependent (among other things) on the nature of the files in
> the repository and which repository back-end is used. I did a
> conversion at ${REALJOB} in December where I converted 1.3GB of CVS
> repository to about 1.5GB in Subversion. For the curious, the
> back-end was FSFS, and an earlier test conversion using the BDB
> back-end took about 2.1GB. I know this is smaller than the FreeBSD
> repository.
Ah, I haven't played with FSFS yet. All my repositories are BDB that
have been upgraded and migrated from version 0.something.
Craig
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: organization
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 parties). The last I heard, subversion did not scale well to the massive amount of files that are in the FreeBSD repository. IIRC it's been a while since this was tested, so it may or may not be true anymore. SVK may partially address this by bypassing libwc. Also, repository size is a big issue (no pun intended). If adding a few hundred megs for repo-copies is prohibitively expensive, I don't think increasing the repo size by many gigabytes would go over very well. Subversion repositories can easily be several times the size of a CVS repository containing the same data. Craig ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Rebooting the kernel without resetting uptime?
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't be done.
Of course you can. Just attach gdb to your running kernel and muck with the
global boottime structure. That's considered cheating, though, so don't do
it!
( a few minutes later )
Hmm, apparently either something has changed in kgdb in 5.3 or I just forgot
the magic incantation, because it doesn't seem to allow modification of
memory -- just "Bad file descriptor". Getting the address from there and
writing to /dev/kmem directly still works though.
the-cheat# uname -r
5.3-STABLE
the-cheat# uptime
9:03PM up 3485 days, 21:44, 1 user, load averages: 0.24, 0.12, 0.12
the-cheat# sysctl kern.boottime
kern.boottime: { sec = 80112, usec = 345099 } Mon May 22 00:20:00 1995
the-cheat#
:-P
Craig
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SSE vs. stack alignment vs. pthread
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 the frame is set up by the thread function) is now 16-byte aligned and everything works just fine ... no bus error anymore. Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SSE vs. stack alignment vs. pthread
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 resolved to make sure that it doesn't crop up later or affect other software... Long story short, audacity is a threaded program. A straight compile of 1.2.2 results in a 100% reproducible bus error that happens on multiple Pentium-4 machines (5.3-STABLE). It always happens at this instruction: 0x081807c4: movaps %xmm0,0xff68(%ebp) Now, at that time ebp is 0xbfadc6c0, so ebp+0xff68 (-0x152) is 0xbfadc56e. Oops, that's not 16-byte aligned like SSE wants. The offsets vary sligthly depending on the compile flags, etc., but the result is always the same -- SIGBUS. My first suspicion was compiler bug. Audacity doesn't inline any SSE code itself -- the movaps is being generated by gcc as part of the pentium4 optimizations. There are two factors that are a little suspicious, though. 1) When I switch out libpthread for libc_r, the crash goes away. Unfortunately, the gdb in 5.3 seems to have forgotten how to debug libc_r based programs so I can't really tell what is different in that case. I just get "Cannot find thread 2: Thread ID=1, generic error". 2) Some searching turned up several similar problems on Linux and NetBSD. The NetBSD post here [http://mail-index.netbsd.org/port-amd64/2004/02/27/0001.html] indicates that it may be related to stack alignment in the thread library. I'm not sure if the ABI requirement discussed there is NetBSD and/or amd64 specific though. HOWEVER -- I inserted some debugging printfs into libpthread to test this theory. The stack it allocates for that thread is located at 0xbfaad000, which is not only 16-byte aligned but page aligned... So I'm reluctant to blame libpthread as it seems to be doing everything right and even going the extra mile. I honestly don't know whether gcc is expecting the alignment to compensate for the return address push or the function prolog, or if it's just losing track of where the stack should be somewhere. I may be over-analyzing the problem at that point :) Another factor to consider is that nobody has reported similar problems in other software... I've been trying to create a simple test case, however it's proving quite difficult to coax gcc into generating SSE code on its own where I want it. It's of course possible that Audacity itself is doing something weird to cause it, but I haven't been able to find anything suspicious or low-level enough to affect the stack alignment. It could just be a heisenbug, and libc_r is different enough to mask the problem. Any and all suggestions from threads/compiler gurus would be very much appreciated. I'm about ready to throw in the towel and just force "-mno-sse -mno-sse2" compiler flags in the makefile... Thanks, Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB developer please look at cdce driver -- (Was: Driver for Yopy PDA)
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 glanced at the code. > > (...and, if meritorious, eventually ported this piece over) Heh, funny you should mention a port. The cdce driver in OpenBSD was ported _FROM_ FreeBSD -- by Daniel Hartmeier, based on my hack of Bill Paul's if_axe code ;) Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB developer please look at cdce driver -- (Was: Driver for Yopy PDA)
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 tarball? I updated the driver at that location a few days ago to make it compile on 5.3 (though I haven't tested it with a real device yet). Thanks to Dave Smith for pointing out to me last week that it wasn't working. Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
m4 is broken -- can't rename builtins (patch in PR)
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 last several months and have yet to run into any problems with it. I guess not many people use the bundled m4 for anything much more complicated than making sendmail.cf files ;) I'm not sure who is the active maintainer for m4 is, or even if there is one. CC: tjr & smkelly as they are the last couple people to touch the code in a while. I hope I'm sending this to the right place :) Thanks! Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB ethernet CDC driver
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 page -- I have a few local patches and such I'd like to share. If and when I ever get time to do that, I'll move this in with it, but the above link should work until then. The list archives will have to suffice as documentation until then, here's a few random comments about it: * It's set up as a standalone kernel module. If you have the kernel source on your system it should be as simple as "cd cdce; make all && make install". That will dump it in /boot/kernel/if_cdce.ko, which can be loaded by any of the normal means. * When you plug in the device, if all goes well, you should end up with a cdce0 network device. Just ifconfig it and go. * It registers itself as the handler for the CDC Ethernet class. If your device doesn't report itself as that, you may have to add a specific device ID for it in the cdce_devs[] structure (get the values from usbdevs -v). If it complains about not being able to find endpoints, try adding it in there with the CDCE_NO_UNION flag. Linux on the Zaurus seems to be slightly non-conformant to the spec, so it may be similar on the iPaq. * The driver generates a random MAC address for the local end rather than trying to read it from the device. While incorrect for real Ethernet adapters, it seems to be fine (and may even be necessary) for these kinds of point-to-point connections. * There is special handling for the Zaurus's nonstandard frame format, but it should be off by default for other devices. This hasn't been tested yet, though :) * The driver is targeted at -CURRENT. It was originally developed against 5.2-RELEASE sources and should still compile fine on those systems. It would probably require some work to back-port to stable though. * Not entirely sure what to do about the copyright message -- I borrowed heavily from the if_axe and if_aue drivers... * BSD license, so feel free to do whatever with it :) * Also applies is my standard disclaimer: It works fine on my system, but may cause your toaster to explode. I used to sometimes get panics on detach, but I think the problem is fixed now. Haven't had one in quite a while, even if I unplug it while transferring something. Good luck! Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB ethernet CDC driver
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 communicate with the host PC. Assuming we don't > already have support, it looks like this will enable the use of a number > of devices. I don't think there is any support in the tree, however I wrote a minimal CDC Ethernet driver a while back in order to talk to my Zaurus. Been meaning to throw it up on a web page or something but I just keep getting too busy :-/ It's pretty bare-bones -- doesn't implement some of the features that a "real" CDC NIC would (multicast, etc.), but is enough to talk to simple devices like the Zaurus. I've never tested it on anything else -- I suspect it wouldn't be too hard to adapt though. If you're interested in looking at it I'll send you a copy or post it somewhere. Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Subversion follow-up
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 STARTEDTIME COMMAND craig 19802 80.5 2.1 15600 10848 pv RN+ 9Feb04 33187:46.67 python ./cvs2svn.py and is still processing commits from mid-2001. Each commit has gotten progressively slower. As my other experiment (importing periodic snapshots from certain branches) has been working beautifully, I'm certain at this point that it's not Subversion itself, but rather the cvs2svn script that is slowing down. I may try again if I hear that the script has been improved in the future. I'm using a barely pre-1.0 version of it that was checked out of the development branch, so I'm reasonably sure not much has changed between it and the 1.0 released one. Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SPAM/virii apparently from freeBSD addresses.
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, Mailman disables your subscription) Most of the Swens I get don't come from the list servers but are sent to my subscription address directly (probably grabbed from posts to the list). I have a separate address for each list to make sorting easier. When I set up freebsd-hackers, I was getting Swen sent to me within an hour of posting to the list for the first time. I filter it but it still wastes bandwidth... Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Subversion/CVS experiment update
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 using cvs2svn.py revision 8587, which is considerably newer than the
version included with 0.37.0. If anyone is contemplating playing with
subversion, I'd highly recommend grabbing this script out of their SVN repo
as it fixes many of the earlier problems.
So far, the only problem I've run into was src/usr.sbin/xntpd. It didn't like
something about the "udel" branch (claims it can't find the origin record for
it). I've hacked around it with the attached patch, which is most likely
wrong. If xntpd is the only problem case, it may be cleaner just to 'fix'
the RCS files. It looks like there's a copy of a vendor branch or something
funny going on.
To follow up to the concerns we had about subversion getting slower after a
large number of commits, I'm now reasonably certain that it's only the import
script that is slowing down. python is gobbling up CPU like there's no
tomorrow, but the amount of time spent in svnadmin actually committing seems
to be negligible.
The other good thing is that memory usage seems to be fairly constant. The
resident set has been hovering around 8M and is not increasing.
I started the import Monday night, so it's been running for about 60 hours
now. python has amassed about 40 hours worth of CPU time:
PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND
19802 craig139 10 12920K 9292K RUN 40.5H 78.91% 78.91% python
So far, it's committed 39,664 revisions and is up to August of 1998. The repo
is sitting at 1.4GB in size (there's a script running in the background
pruning the db logs every 60 seconds) and cvs2svn is using ~800M of temporary
files. Looks like it's currently working on the initial import of picobsd ;)
I'm doing other stuff on the machine during the day -- XFree86, gkrellm, KDE,
etc. So far ULE is keeping interactive performance snappy, though when I'm
doing other things the niced processes tend to get a little "bursty".
cvs2svn has it to itself for the other 16 hours.
Will follow up on success/failure of the import, which at this rate will
probably be done sometime next week...
Craig
--- cvs2svn.py.orig Mon Feb 9 19:52:07 2004
+++ cvs2svn.py Mon Feb 9 19:53:56 2004
@@ -1709,7 +1709,8 @@
else:
sys.stderr.write("%s: no origin records for branch '%s'.\n"
% (error_prefix, name))
- sys.exit(1)
+ return
+# sys.exit(1)
parent_key = parent[name]
parent = marshal.loads(self.db[parent_key])
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Subversion/CVS experiment summary
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 the same as the 0.35 version. For some reason it looks like they just re-tagged the old version rather than bring in the changes from HEAD... > > One thing that may have made a difference is that so far I've been > > importing things in chunks rather than trying to do the whole repo at > > once. > > Yes, I was afraid though that commits might have spanned subtrees. But then > again, even if they did they would just get committed as separate revisions > to the tree, and I suppose one could live with that. There probably are some commits that do. Only reason I did it like that was to try to trap failure cases more quickly without having to wait for it to get through stage 1 on the whole repo. My plan has always been to go back and try to convert the whole thing when I was sure it would import cleanly and had the resources to do it (the fastest CPU machine I have probably doesn't have enough disk space right now to handle it). > > Does the Python version do the same thing? I didn't think to look at > > memory usage very closely while it was running :-/ > > As far as I understood it builds a disk cache instead of using malloc(). > This might explain the slowness :) Ok, that's consistent with what I saw here. It looked like it created several large temporary bdb databases, but I don't remember any excessive swapping going on. > Yes, that's the idea. You 'just' need a tool that can determine changesets > from a CVS repository to automate this. See > > http://wiki.gnuarch.org/moin.cgi/Arch_20and_20CVS_20in_20the_20same_20tree > > but substitute Subversion for arch :) Makes sense. I believe you mentioned earlier that post-commit hooks could be used for this? But that of course requires assistance from the repomaster. It might also be possible to rig up a script to monitor the cvs-all mailing list and get its changesets from there... > It is, but it does work. Maybe I'll test and see if I can 'port' those > scripts to Subversion :) Yes, it does work as long as your users are relatively trusted and you keep good backups :). Still, it would probably be the most painless transition path to use that over ssh. In regards to the speed test: ARGH! svn dump died on me with this message: * Dumped revision 18576. * Dumped revision 18577. * Dumped revision 18578. * Dumped revision 18579. * Dumped revision 18580. svn: Invalid change ordering: non-add change on deleted path If it's really invalid I wonder how it ended up in the repo in the first place. Not good. I'll have to do some digging to find out what causes that. Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Subversion/CVS experiment summary
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 LastChangedRevision: 8527, with a date of Jan. 29. It looks like that version is slightly newer than the one included with 0.37 (Rev 8512). One thing that may have made a difference is that so far I've been importing things in chunks rather than trying to do the whole repo at once. > but although it looks like it handles things much better (even vendor > branches etc), it loads EVERYTHING into memory -- which means that it > eventually grew to 1G of memory/swap at which point my memory was > exhausted, and this was at pass 2 of 7... Does the Python version do the same thing? I didn't think to look at memory usage very closely while it was running :-/ > > Comments on importing: It's SLOOW. It took 43.9 hours just for > > src/sys, and this is a relatively speedy system! It starts out at a > > pretty good pace, but the more commits it processes, the slower each one > > seems to take. > > That doesn't bode well. Is committing in the new SVN repository also slow? No, creating a new branch and committing new and changed files to it seems to be just as quick as with an empty repository. I haven't delved into the script enough to know for sure, so this is a wild guess, but I think the speed issue has to do with the script itself. I'm guessing that the method it uses to track the status/branch/etc. of the RCS files is subject to a linear slowdown. I'm going to attempt to verify this by doing a dump / load cycle on the repo that everything was imported into. If it goes quickly then we can assume it's the conversion script. If not, then there are bigger problems... > My thoughts were now going to do something like Tom Lord proposed for an > Arch gateway -- just import a CVS working copy into SVN at a certain > cut-off date, and setup a bi-directional gateway between the two. If I'm reading that right, it sounds similar to a thought I had about just routinely checking out snapshots and committing them on a vendor branch. Of course you'd have to do that separately for each branch you're interested in. IMO, I find it immensely useful to have the entire history of a file at hand. > Actually, would a sort of access control wrapper that is now also used with > the FreeBSD CVS repository not work? I do agree that it would be nice to > have per-directory access control with the svnserve method. Yes, I think the same sort of access hooks (pre-commit?) can be used. The Subversion manual even mentions that, I just forgot about it... That method has always seemed a little... hackish to me. You still need write access (file permissions) to almost the entire repo so it does nothing against editing the files directly -- though with SVN this is a little more difficult as it's all bdb files rather than plain text. Maybe there's a more secure way to do it with a restricted shell that I just don't know about. > > [ repeated merges ] > Which is a shame, this would be a major selling point. On the other hand, > considering the amount of work done and the fact that it really works quite > well already (at least for my small repository) should make people want to > switch :) In the release notes for 0.37 there is a brief blurb about "'svn merge' now notices ancestry by default". I'm not sure exactly what that means or if it's related... > > It also looks as if Subversion 0.37 (aka 1.0-RC) has just been released. > > I'll have to take a look at it and see if any of the problems noted above > > have been resolved. > > Please let me know the results! Will do! My local Subversion server (one running Apache, not the machine I've been doing the tests on) had just finished upgrading the port. I don't think it needs a dump/load cycle but I'm doing one anyway just to be safe... Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Subversion/CVS experiment summary
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, some is more FreeBSD-specific. NOTE: I'm not trying to push one SCM over the other or suggest that CVS is wholly inadequate. This is merely the result of an evaluation for my personal use, and I thought I'd post it in case anyone was interested. CVS has been used by the FreeBSD project for a LONG time for good reasons. Despite its shortcomings, I suspect that it will be in use for quite a while longer. - Section the 1st - Motive - My main motivation for these tests was to bring my local modifications to FreeBSD into some semblance of order. It seems I've amassed a bit of a collection of local patches, 3rd party patches, and side projects -- some of which are mutually exclusive or apply to different branches. Simply keeping a working copy with my changes in it works fine for one project but becomes painful when there are several. I'd also like to be able to keep version history for my modifications. I've heard good things about Perforce, and its effortless merge functionality looks really slick. If I'm ever involved with a major commercial coding project, I'll definitely give it some consideration. For my "free-time" projects however it's not really an option. A couple of my local mods are in a bit of a grey area as far as the 'non-commercial' license goes, so I'd rather avoid that whole issue. - Section the 2nd - Setup and conversion - Most of my tests were performed on the src/sys portion of the repository. It seemed to be large enough that I could get a general idea of how well Subversion scales, but small enough that I wouldn't spend all week waiting for the import to complete. All tests were done on a Pentium 4 2.8 GHz system with 512MB RAM. I used a local repository on one disk and the working directories on another (for both CVS and SVN). These tests have been done over the course of the last week and a half, using subversion-0.35.1_1. I've heard of attempts to convert the repo for testing using the cvs2svn.py failing (for more details, see the thread at http://docs.freebsd.org/cgi/getmsg.cgi?fetch=640133+0+archive/2004/freebsd-hackers/20040111.freebsd-hackers). These problems seem to be fixed in the most recent version of the script -- I have been able to successfully import sys, bin, sbin, and lib so far. The next target for testing is contrib as it seems to be the most likely candidate for problems with all those vendor branches. Comments on importing: It's SLOOW. It took 43.9 hours just for src/sys, and this is a relatively speedy system! It starts out at a pretty good pace, but the more commits it processes, the slower each one seems to take. For my purposes I would also need some method of incrementally updating the repository with any new commits made to CVS. This doesn't exist yet, but I'm thinking about trying to hack cvs2svn to do this. Kind of an inverse vendor branch I guess. - Section the 3rd - Head to Head - Yeah, I know comparing Subversion and CVS isn't a fair test -- SVN is designed to be much more than CVS. But it's a comparison that will be inevitably made, so might as well get it out of the way. Bad points (for SVN): * Repo size: The src/sys part of the tree alone is 1.2GB. The same portion of the repo in CVS is only 313MB. I had to keep a script running to routeinly purge unused database logs to avoid running out of disk space during the import. * Working set size: SVN keeps a complete copy of every file that is checked out in a hidden directory analogous to "CVS" directories. This does have some advantages outlined below, but effectively doubles the size of your working directory. * Speed: 0.35 is considerably slower than CVS for some operations. svn checkout is on average about 6 times slower than cvs checkout. Interestingly, CVS seems to benefit from the buffer cache much more than SVN does -- nearly a 50% decrease in execution time for CVS once the cache was populated. Please note however that checking the same thing out over and over isn't a very useful thing to do, and SVN fares better with the more common operations. * Not as thouroughly tested with large repositories. One advantage CVS has is that
Re: kernel enviroment in sysctl MIB
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 to see the BTX variables. An install program could use this > to see an INSTALL_SERVER=install.company.com variable (etc...) to use as > install server. The BTX loader could provide these variables at install > boot time, thus enableing fully automated installs. I've been using the 'kenv' program for some time to do this. For my purposes it seems to work quite well (have loader display a menu with an option of whether or not to start X after bootup). It seems to do the trick for me -- if you need it from a program rather than a shell script you may want to look at the source for kenv(1) to see how it gets its information. Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: An experiment: 64-bit time_t on IA-32 (5.2-RC)
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. I notice time_t is 'long' on i386 so bde's > ia32-with-64-bit-longs will also have 64-bit time_t. That may be what I'm thinking of. > Looks like I was wrong about the adjacent field being spare - it seems > it _has_ been used for high-res timestamps since I looked last. The discussion I did find mentioned that that field had been used for milliseconds or something. Hopefully by 2038 there won't be too many UFS1 filesystems left ;) > I was thinking of a totally independent implementation - eg the > algorithms in Edward M. Reingold's "Calendrical Calculations". > Agreeing with FreeBSD on an iA64 or amd64 could just be common bugs. A, math :) I'll try cooking something up and see how it turns out. I'll also run those numbers through my trusty HP-48 and see what it thinks as well. > >Right now I'm recompiling world again because I didn't notice that struct > >timeval had long hard-coded for tv_sec :( > > gcc should be able to pick this up for you. I'm not sure I understand... Right now I'm really wishing I had gone ahead and implemented some compat functions in libc and the kernel so that old binaries would work. Being without cvsup is no fun at all. I tried to update ports using anoncvs, but that was slow and eventually died. > This isn't true now on Alpha and SPARC so I thought they had all been > ironed out. You may still get bitten if sizeof(time_t) > sizeof(long). I think that's exactly what's happening. All the cases I've isolated so far involve trying to stuff a time_t into a long (or sometimes even an int!), so if sizeof(long) > sizeof(time_t) it wouldn't be a problem. The kdelibs one is no fun. There are a couple places in KDE where a time_t is stored in some sort of configuration object -- the interface is slightly reminiscent of the Windows registry. The storage function is overloaded, so if I make sure there is one for long long it will be able to store it just fine no matter what the architecture. Getting it out is trickier since you have to know ahead of time what the type is in order to call the correct retrieval function (readLongNum, readLongLongNum, etc.) Currently I'm thinking about doing something like #if sizeof(time_t) == sizeof(long) #define readTimeTNum readLongNum #elif sizeof(time_t) == sizeof(long long) #define readTimeTNum readLongLongNum ... but that's really ugly. Surely there's a better way? Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
