New scsi_target code
I have rewritten the scsi_target driver and usermode client with a much simpler model suggested by Justin Gibbs. The kernel driver receives commands in the form of CCBs via write(2) and returns completed CCBs to usermode via read(2). The included sample client is much simpler as well, implementing only RBC (simple hard drive command set). What is this useful for? It allows anyone with an HBA to emulate various SCSI target devices for reverse engineering initiator implementations, debugging, host-host communication, and many other uses. Because it operates at the CAM layer, it should work with multiple transports (parallel SCSI, FC, ...) Currently, the code works to the point of passing camcontrol rescan and a few reads and writes with two Adaptec 2940U2Ws (ahc driver). However, there is an unknown bug where after a few commands (even just TUR), the target hangs after sending a CTIO and the initiator aborts the command. As such, the code is ALPHA QUALITY and may hang your system. For more information, see the included README and manpages. Comments are needed and appreciated. http://www.root.org/~nate/freebsd/ -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New scsi_target code
Nate, On Thu, Sep 05, 2002 at 01:54:08AM -0700, Nate Lawson wrote: I have rewritten the scsi_target driver and usermode client with a much simpler model suggested by Justin Gibbs. The kernel driver receives This sounds like excellent work and I can't wait to check it out further. Whilst looking into the problem of USB-ATA bridge support I was recently faced with the problem of writing various ATA-SCSI command translations, which involved emulating a SCSI device, so I imagine your code should be very useful. Thank you! BMS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
FreeBSD Problems with dc(4) ADMtek AN985 chip
Hi everybody, (I also wrote to the linux tulip list, maybe someone has encountered the bug in linux too as I do ?) My notebook has a Accton EN2242 network chip, which is integrated into a VIA PN133 chipset. I encounter serious connection problems as desribed in the manpage. I have to replug the cable over and over again till it works. And then the connection stays about some seconds and then it get wedged again. Unusable ... From a cold boot into Linux, is see the same symptoms as FreeBSD. Linux kernel 2.4.9-13 ... The windows driver seems to work :-( . From the FreeBSD dc manpage. The ADMtek AL981 chip (and possibly the AN985 as well) has been observed to sometimes wedge on transmit: this appears to happen when the driver queues a sequence of frames which cause it to wrap from the end of the transmit descriptor ring back to the beginning. The dc driver attempts to avoid this condition by not queuing any frames past the end of the transmit ring during a single invocation of the dc_start() routine. This workaround has a negligible impact on transmit performance. But this workaround seems not to work for me. For some reason, replugging the cable works for me, ifconfig (down/up) does not. Whe link always stays up, it is just the reciever queue with is wedged. Have other people the same problem with the dc driver ? If you own such a card here: Linksys EtherFast LNE100TX Accton EN2242 Please tell me your experiences. Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
double page fault(s)
Hi all, I've been experiencing double page faults on several FreeBSD 4.x systems with a custom device driver, which I believe is somehow responsible. Searching the freebsd-hackers mailing list archives I found several mentions of problems similar to mine; it seemed that the consensus is that this problem is almost always caused by kernel stack mistreatment. I spent quite a bit of time trying to approach the problem with DDB and KGDB, but while I'm able to break into the debugger when the second fault occurs, I have not yet been able to investigate the offending stack. One approach I've looked at was suggested in response to the Debugging double page fault thread; it was (if I understand it correctly) suggested that if one can find a way to break on the second handler, then by saving a copy of or a reference to the first trap frame in the first fault handler, one would be able to investigate that frame (from said second). Unfortunately, my knowledge of the FreeBSD kernel is still poor, I'm unsure about the appropriate places to catch the first trap and where to save the fault frame. I'm hoping that you can point me at additional sources of information or have other hints. Thanks, -- christian zander [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: double page fault(s)
if you know which process stack was operational at the first page fault, then you can dump THAT stack with 'tr PID' the error messages MIGHT give thatinfo.. failing that you MAY have to try all the active pids (ps in ddb should give you a hint as to which to try.. it will not be sleeping) until you find one which has a stack that is in the right neighborhood. It MAY not work however.. it all depends on a number of factors, such as teh last time the process run and how much damage has occured. Also the previos stack pointer is savevd among the stuff saved on the double fault.. you MAY be able to find it (check an x86 manual) Then you can dump it using x/x and maybe you can back track it by hand.. just some ideas... On Thu, 5 Sep 2002, Christian Zander wrote: Hi all, I've been experiencing double page faults on several FreeBSD 4.x systems with a custom device driver, which I believe is somehow responsible. Searching the freebsd-hackers mailing list archives I found several mentions of problems similar to mine; it seemed that the consensus is that this problem is almost always caused by kernel stack mistreatment. I spent quite a bit of time trying to approach the problem with DDB and KGDB, but while I'm able to break into the debugger when the second fault occurs, I have not yet been able to investigate the offending stack. One approach I've looked at was suggested in response to the Debugging double page fault thread; it was (if I understand it correctly) suggested that if one can find a way to break on the second handler, then by saving a copy of or a reference to the first trap frame in the first fault handler, one would be able to investigate that frame (from said second). Unfortunately, my knowledge of the FreeBSD kernel is still poor, I'm unsure about the appropriate places to catch the first trap and where to save the fault frame. I'm hoping that you can point me at additional sources of information or have other hints. Thanks, -- christian zander [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Problems with dc(4) ADMtek AN985 chip
Hi, The NIC is the external interface on my gateway. It was originally connected to an old HP 8-port 10bT hub and is now connected directly to a Westel DSL bridge. It has worked seemingly without problems handling the 768/128 DSL traffic. I say seemingly because I've never bothered to really push the NIC and I've never seen any link-level problems. 10 or 100 mbit with your Westel DSL bridge ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Problems with dc(4) ADMtek AN985 chip
Martin Blapp wrote: Hi, The NIC is the external interface on my gateway. It was originally connected to an old HP 8-port 10bT hub and is now connected directly to a Westel DSL bridge. It has worked seemingly without problems handling the 768/128 DSL traffic. I say seemingly because I've never bothered to really push the NIC and I've never seen any link-level problems. 10 or 100 mbit with your Westel DSL bridge ? 10mbit half-duplex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Problems with dc(4) ADMtek AN985 chip
Hi, I have a 100mbit full-duplex connection, maybe this is the difference ? 10mbit half-duplex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Problems with dc(4) ADMtek AN985 chip
Martin Blapp wrote: Hi, I have a 100mbit full-duplex connection, maybe this is the difference ? 10mbit half-duplex Since the issue seems to be the sort where high amounts of traffic would be a triggering factor, it's quite possible. Give me 20 minutes or so and I'll go swap the interfaces around so the dc is on the inside connected to 100mbit/full and flood the link. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
PCMCIA questions: mapping attribute and common memory?
Hey there, I have a few questions regarding a PCMCIA driver I'm writing. How do I map in attribute and common memory blocks from a PCMCIA card? Is this done on my behalf by the pcic(4) driver? Does it scan the CIS tuples for me and perform the appropriate allocations? If so, how do I get at the resource? If not, how would I go about doing this myself in the driver? And what would I want to put in my driver's xxx_probe() routine? I've been looking over the ray(4) and xe(4) drivers, which have given me some hints, but I'd appreciate clarification. Thanks! BMS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PCMCIA questions: mapping attribute and common memory?
In message [EMAIL PROTECTED], Bruce M Simpson writes: Hey there, I have a few questions regarding a PCMCIA driver I'm writing. How do I map in attribute and common memory blocks from a PCMCIA card? Is this done on my behalf by the pcic(4) driver? Does it scan the CIS tuples for me and perform the appropriate allocations? If so, how do I get at the resource? If not, how would I go about doing this myself in the driver? And what would I want to put in my driver's xxx_probe() routine? Suggest you look at the sys/dev/sio/sio_pccard.c file... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PCMCIA questions: mapping attribute and common memory?
In message [EMAIL PROTECTED], Bruce M Simpson writes: On Thu, Sep 05, 2002 at 09:22:11PM +0200, Poul-Henning Kamp wrote: Suggest you look at the sys/dev/sio/sio_pccard.c file... I forgot to mention I'm working on -STABLE. =o) Don't, that's a dead end and very very different from how the NEWCARD world will look in the future. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Problems with dc(4) ADMtek AN985 chip
Darren Pilgrim wrote: Martin Blapp wrote: I have a 100mbit full-duplex connection, maybe this is the difference ? 10mbit half-duplex Since the issue seems to be the sort where high amounts of traffic would be a triggering factor, it's quite possible. Give me 20 minutes or so and I'll go swap the interfaces around so the dc is on the inside connected to 100mbit/full and flood the link. I swapped the NICs around and hammered the LNE100TX for at least 30 minutes straight. I didn't get any problems. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PCMCIA questions: mapping attribute and common memory?
On Thu, Sep 05, 2002 at 09:47:38PM +0200, Poul-Henning Kamp wrote: I forgot to mention I'm working on -STABLE. =o) Don't, that's a dead end and very very different from how the NEWCARD world will look in the future. After playing with 'pccardc enabler' and looking at if_xe.c, I now understand why OLDCARD Sucks(tm). I'm eager to get this particular device working on my present platform though, so I'm going to fight on, with the intention of porting it to NEWCARD as soon as possible. BMS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PCMCIA questions: mapping attribute and common memory?
In message: [EMAIL PROTECTED] Bruce M Simpson [EMAIL PROTECTED] writes: : How do I map in attribute and common memory blocks from a PCMCIA card? You generally don't map attribute memory. With one exception (the raylan cards), there's no hardware in the attribute memory section and it is just used to store the cis. : Is this done on my behalf by the pcic(4) driver? Yes. : Does it scan the CIS tuples for me and perform the appropriate allocations? Yes. : If so, how do I get at the resource? : If not, how would I go about doing this myself in the driver? bus_alloc_resource() : And what would I want to put in my driver's xxx_probe() routine? Ideally, you'd just match the OEM ID and vendor info of the card. Less ideally, you'd match the strings in the CIS. : I've been looking over the ray(4) and xe(4) drivers, which have given me : some hints, but I'd appreciate clarification. Those are the two worst ones to look at. Don't do what they do, as the ray(4) hardware is weird and the xe(4) driver was written before we could read the cis from the kernel. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PCMCIA questions: mapping attribute and common memory?
In message: [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: : In message [EMAIL PROTECTED], Bruce M Simpson writes: : On Thu, Sep 05, 2002 at 09:22:11PM +0200, Poul-Henning Kamp wrote: : Suggest you look at the sys/dev/sio/sio_pccard.c file... : : I forgot to mention I'm working on -STABLE. =o) : : Don't, that's a dead end and very very different from how the : NEWCARD world will look in the future. Actually, much of the pccard driver interface is identical between the two systems. Look at the ep driver for a relatively sane way of dealing. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PCMCIA questions: mapping attribute and common memory?
In message: [EMAIL PROTECTED] Bruce M Simpson [EMAIL PROTECTED] writes: : On Thu, Sep 05, 2002 at 09:47:38PM +0200, Poul-Henning Kamp wrote: : I forgot to mention I'm working on -STABLE. =o) : Don't, that's a dead end and very very different from how the : NEWCARD world will look in the future. : : After playing with 'pccardc enabler' and looking at if_xe.c, I now understand : why OLDCARD Sucks(tm). pccardc enabler sucks. if_xe.c in stable does all kinds of weird things. : I'm eager to get this particular device working on my present platform : though, so I'm going to fight on, with the intention of porting it to : NEWCARD as soon as possible. That's mostly doable. Most of the goo to have a driver support oldcard and newcard is present in -stable. I have some more good to MFC tonight or this weekend (just got RE approval). if_wi_pccard.c might be a better thing to look at for something that supports both oldcard and newcard in a sane way. Maybe if you provided more details on the hardware, I could provide more detailed answers, privately if necessary. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Usenix 2002 FreeBSD Developer Summit III -- why no oggs?
Hi! I've read the notes as of 2 September, 2002 from the USENIX ATC 2002 FreeBSD Developer Summit, which were made available recently. As a very good addition to them, I suggest putting online some .oggs (or .mp3s) next time, with recorded speeches, just like guys from recent linux kernel summit did (ksmp3rep.sourceforge.net)? Sounds like a good idea to me. Opinions? ./danfe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NS DP83820 gigabit MAC
Bruce M Simpson writes: | On Tue, Sep 03, 2002 at 09:30:43PM +0200, Robert Fenech wrote: | I've been desperately looking for some help regarding the DP83820. Is | anyone willing to help me pls? | | NetBSD would seem to have a driver for this. | http://www.tac.eu.org/cgi-bin/man-cgi?gsip+4 | | AUTHORS | The gsip driver was written by Jason R. Thorpe [EMAIL PROTECTED]. Why not use nge(4) which now supports fiber versions: NAME nge - National Semiconductor PCI gigabit ethernet adapter driver SYNOPSIS device miibus device nge DESCRIPTION The nge driver provides support for various NICs based on the National Semiconductor DP83820 and DP83821 gigabit ethernet controller chips, including the following: Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
