From jason.harmening at gmail.com Sun Feb 8 10:01:16 2009 From: jason.harmening at gmail.com (Jason Harmening) Date: Sun Feb 8 10:01:22 2009 Subject: PCI-Express interrupt issues Message-ID: <20090208113202.6d591589@CORONA> Hi All, I'm the maintainer for the FreeBSD cx88 driver (multimedia/cx88). I've recently encountered some issues w/ interrupt handling, specifically on PCI-Express systems, and I was hoping someone would be able to help me. Issue #1: The cx88 driver has split interrupt handling between filters and ithreads since filters became available w/ 7.0. For the past year, the filters have been set up to return FILTER_SCHEDULE_THREAD if the status register indicates an interrupt, FILTER_STRAY otherwise. Everything has worked fine. However, I recently stumbled across some documentation indicating that FILTER_SCHEDULE_THREAD shouldn't be returned alone--instead, the filter should return FILTER_HANDLED | FILTER_SCHEDULE_THREAD. So I modified the cx88 driver to do that instead, and that's where things turned strange: On machine #1, which uses a VIA K8T800 chipset, everything still worked fine. On machine #2, which uses a VIA K8T890 chipset, the threaded interrupt handlers were no longer invoked. It's as though the bus driver saw FILTER_HANDLED in the bitmask and assumed the interrupt was already processed without checking to see if an ithread should be scheduled. What's interesting is that the only significant difference between the K8T800 in machine #1 and the K8T890 in machine #2 is that the K8T890 supports PCI-Express, while the K8T800 is PCI-only. Issue #2: We're working on adding support for a newer generation of PCI-Express cx88 devices, which support message signaled interrupts. When MSIs are enabled for these boards, the interrupts seem to simply stop firing after the first several. During transfers across the cx88's onboard I2C bus, the first several (e.g. 8-10) bytes will be transferred successfully, which means the I2C transfer interrupts are working for those bytes. But after that the passive thread will timeout waiting to be signaled by the interrupt handler. The I2C interrupts are handled entirely in their own filter (no ithread here), and they can occur with high frequency (e.g. several hundred per second for large firmware loads). We don't see anything in the system log indicating that an interrupt storm is detected or that throttling is coming into play here. If we revert to legacy INTx interrupts, everything works fine. All other transfer logic is identical between the legacy and MSI cases. The MSI behavior is identical between machine #2 w/ the K8T890 and a third machine w/ an nForce4. We haven't been able to try it anywhere else yet. I'm hoping someone will be able to shed some light on these issues--neither one is a real emergency, but they're both kind of troubling. Thanks, Jason From freebsddog at hotmail.com Mon Feb 9 07:04:09 2009 From: freebsddog at hotmail.com (Jim Andersson) Date: Mon Feb 9 07:04:36 2009 Subject: 8187SE driver In-Reply-To: <20090128103926.GA82455@freebsd.weongyo.org> References: <20090116040425.GB66457@freebsd.weongyo.org> <20090119101623.GC81329@freebsd.weongyo.org> <20090128103926.GA82455@freebsd.weongyo.org> Message-ID: > From: weongyo.jeong@gmail.com > Date: Wed, 28 Jan 2009 19:39:26 +0900 > To: freebsddog@hotmail.com > CC: freebsd-drivers@freebsd.org > Subject: Re: FW: 8187SE driver > > On Tue, Jan 27, 2009 at 02:23:33PM +0100, Jim Andersson wrote: > > > > From: freebsddog@hotmail.com > > To: weongyo@freebsd.org > > Subject: RE: 8187SE driver > > Date: Tue, 27 Jan 2009 14:22:15 +0100 > > > > > From: weongyo.jeong@gmail.com > > > Date: Mon, 19 Jan 2009 19:16:23 +0900 > > > To: freebsddog@hotmail.com > > > CC: freebsd-drivers@freebsd.org > > > Subject: Re: 8187SE driver > > > > > > On Sat, Jan 17, 2009 at 04:16:43PM +0100, Jim Andersson wrote: > > > > > > > > > From: weongyo.jeong@gmail.com > > > > > Date: Fri, 16 Jan 2009 13:04:26 +0900 > > > > > To: freebsddog@hotmail.com > > > > > CC: freebsd-drivers@freebsd.org > > > > > Subject: Re: 8187SE driver > > > > > > > > > > On Thu, Jan 15, 2009 at 11:48:32AM +0100, Jim Andersson wrote: > > > > > > > > > > > > Hi! > > > > > > > > > > > > Is there any chance of getting my wireless card running in > > > > > > CURRENT. Linux says it?s a Realtek 8187SE wireless network > > > > > > card. I have seen some driver for other 8187 cards, is it > > > > > > possible to force such driver to try identify the card? > > > > > > > > > > > > > > > > > > Here is the output of pciconf -lv in my FreeBSD > > > > > > CURRENT:none1@pci0:1:0:0: class=0x028000 card=0x819910ec > > > > > > chip=0x819910ec rev=0x22 hdr=0x00vendor = 'Realtek > > > > > > Semiconductor'class = network . > > > > > > > > > > I think a thing you can try is that, NDISulator using ndis(4). AFAIK > > > > > there's no support for 8187SE driver until now. > > > > > > > > > > regards, > > > > > Weongyo Jeong > > > > > > > > > > > > > I tried ndisulator but it didn?t work. I used the INF and the SYS > > > > file for Windows Xp. I even tried including a cat file. > > > > Although one thing changed, the card is no longer listed when i > > > > type pciconf -lv. Dunno if that?s good or bad? > > > > > > It looks it's a bad news. Could you please show me dmesg's ouput and > > > steps you followed? > > > > > > regards, > > > Weongyo Jeong > > > > > > > As far as I can see the only thing in dmesg regarding this card is: > > > > pci1: on pcib3 > > pci1: at device 0.0 (no driver attached) > > > > What I did was this: I used my windows xp drivers for the card that I > > recieved with the computer. I used the .sys and the inf file. The > > driver loads good but no interface is shown. Is the someway to force > > the driver to attach to pci2 somehow? > > Normally if it works well the device should be detected automatically > and should show some messages related with ndis(4). It looks there are > another problems in your case. BTW there's no way to force the driver > to attach. > > > Or is there some way to use a linux driver? Linux says its a realtek > > 8187SE. > > No way to use the linux driver. > > regards, > Weongyo Jeong > It seems there has been a recent release of a driver for MAC/OSX according to this page: http://forums.msiwind.net/mac/great-news-regarding-rtl8187se-wifi-module-t3986.html perhaps I can persuade them into remaking a freebsd driver, Darwin is not that far from BSD right? ;-) _________________________________________________________________ Snygga till dina bilder snabbt, enkelt och gratis med PhotoGallery http://download.live.com/photogallery From jhb at freebsd.org Mon Feb 9 07:53:36 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Feb 9 07:55:06 2009 Subject: PCI-Express interrupt issues In-Reply-To: <20090208113202.6d591589@CORONA> References: <20090208113202.6d591589@CORONA> Message-ID: <200902090946.46917.jhb@freebsd.org> On Sunday 08 February 2009 12:32:02 pm Jason Harmening wrote: > Hi All, > > I'm the maintainer for the FreeBSD cx88 driver (multimedia/cx88). I've > recently encountered some issues w/ interrupt handling, specifically on > PCI-Express systems, and I was hoping someone would be able to help me. > > Issue #1: > > The cx88 driver has split interrupt handling between filters and > ithreads since filters became available w/ 7.0. For the past year, the > filters have been set up to return FILTER_SCHEDULE_THREAD if the status > register indicates an interrupt, FILTER_STRAY otherwise. Everything > has worked fine. > > However, I recently stumbled across some documentation indicating that > FILTER_SCHEDULE_THREAD shouldn't be returned alone--instead, the filter > should return FILTER_HANDLED | FILTER_SCHEDULE_THREAD. So I modified > the cx88 driver to do that instead, and that's where things turned > strange: > > On machine #1, which uses a VIA K8T800 chipset, everything still worked > fine. > > On machine #2, which uses a VIA K8T890 chipset, the threaded interrupt > handlers were no longer invoked. It's as though the bus driver saw > FILTER_HANDLED in the bitmask and assumed the interrupt was already > processed without checking to see if an ithread should be scheduled. > What's interesting is that the only significant difference between the > K8T800 in machine #1 and the K8T890 in machine #2 is that the K8T890 > supports PCI-Express, while the K8T800 is PCI-only. Are you seeing this only on 7.0? Also, do you have 'INTR_FILTER' enabled in the kernel? If you don't, then your ithread will never be called if you have a filter (actually, the bus_setup_intr() should fail in that case if you specify both). > Issue #2: > > We're working on adding support for a newer generation of PCI-Express > cx88 devices, which support message signaled interrupts. > When MSIs are enabled for these boards, the interrupts seem to simply > stop firing after the first several. During transfers across the > cx88's onboard I2C bus, the first several (e.g. 8-10) bytes will be > transferred successfully, which means the I2C transfer interrupts are > working for those bytes. But after that the passive thread will timeout > waiting to be signaled by the interrupt handler. The I2C interrupts > are handled entirely in their own filter (no ithread here), and they can > occur with high frequency (e.g. several hundred per second for large > firmware loads). We don't see anything in the system log indicating > that an interrupt storm is detected or that throttling is coming into > play here. > > If we revert to legacy INTx interrupts, everything works fine. All > other transfer logic is identical between the legacy and MSI cases. > The MSI behavior is identical between machine #2 w/ the K8T890 and a > third machine w/ an nForce4. We haven't been able to try it anywhere > else yet. > > > I'm hoping someone will be able to shed some light on these > issues--neither one is a real emergency, but they're both kind of > troubling. The only thing I can think of is perhaps a hardware bug. MSI interrupts are edge triggered while INTx are level. However, if a device implements MSI by "listening" to the level-triggered interrupt and sending a message when the level changes and it ever has a bug where it fails to send a message, then it won't recover. FreeBSD doesn't do any masking of interrupts for MSI, it just installs the handler in the IDT and calls it for every interrupt. Thus, if you are not seeing interrupts it is likely not an issue with FreeBSD itself, but an issue in the hardware (or possibly the driver if your interrupt handler doesn't fully ACK something perhaps). -- John Baldwin From jason.harmening at gmail.com Mon Feb 9 08:11:28 2009 From: jason.harmening at gmail.com (Jason Harmening) Date: Mon Feb 9 08:11:35 2009 Subject: PCI-Express interrupt issues In-Reply-To: <200902090946.46917.jhb@freebsd.org> References: <20090208113202.6d591589@CORONA> <200902090946.46917.jhb@freebsd.org> Message-ID: <2d1264630902090811p761b0a14w997985779aad8748@mail.gmail.com> On Mon, Feb 9, 2009 at 8:46 AM, John Baldwin wrote: > On Sunday 08 February 2009 12:32:02 pm Jason Harmening wrote: >> Hi All, >> >> I'm the maintainer for the FreeBSD cx88 driver (multimedia/cx88). I've >> recently encountered some issues w/ interrupt handling, specifically on >> PCI-Express systems, and I was hoping someone would be able to help me. >> >> Issue #1: >> >> The cx88 driver has split interrupt handling between filters and >> ithreads since filters became available w/ 7.0. For the past year, the >> filters have been set up to return FILTER_SCHEDULE_THREAD if the status >> register indicates an interrupt, FILTER_STRAY otherwise. Everything >> has worked fine. >> >> However, I recently stumbled across some documentation indicating that >> FILTER_SCHEDULE_THREAD shouldn't be returned alone--instead, the filter >> should return FILTER_HANDLED | FILTER_SCHEDULE_THREAD. So I modified >> the cx88 driver to do that instead, and that's where things turned >> strange: >> >> On machine #1, which uses a VIA K8T800 chipset, everything still worked >> fine. >> >> On machine #2, which uses a VIA K8T890 chipset, the threaded interrupt >> handlers were no longer invoked. It's as though the bus driver saw >> FILTER_HANDLED in the bitmask and assumed the interrupt was already >> processed without checking to see if an ithread should be scheduled. >> What's interesting is that the only significant difference between the >> K8T800 in machine #1 and the K8T890 in machine #2 is that the K8T890 >> supports PCI-Express, while the K8T800 is PCI-only. > > Are you seeing this only on 7.0? Also, do you have 'INTR_FILTER' enabled in > the kernel? If you don't, then your ithread will never be called if you have > a filter (actually, the bus_setup_intr() should fail in that case if you > specify both). All machines are running 7.1-STABLE. Filters are enabled across the board, and reverting to just returning FILTER_SCHEDULE_THREAD fixes the issue. > >> Issue #2: >> >> We're working on adding support for a newer generation of PCI-Express >> cx88 devices, which support message signaled interrupts. >> When MSIs are enabled for these boards, the interrupts seem to simply >> stop firing after the first several. During transfers across the >> cx88's onboard I2C bus, the first several (e.g. 8-10) bytes will be >> transferred successfully, which means the I2C transfer interrupts are >> working for those bytes. But after that the passive thread will timeout >> waiting to be signaled by the interrupt handler. The I2C interrupts >> are handled entirely in their own filter (no ithread here), and they can >> occur with high frequency (e.g. several hundred per second for large >> firmware loads). We don't see anything in the system log indicating >> that an interrupt storm is detected or that throttling is coming into >> play here. >> >> If we revert to legacy INTx interrupts, everything works fine. All >> other transfer logic is identical between the legacy and MSI cases. >> The MSI behavior is identical between machine #2 w/ the K8T890 and a >> third machine w/ an nForce4. We haven't been able to try it anywhere >> else yet. >> >> >> I'm hoping someone will be able to shed some light on these >> issues--neither one is a real emergency, but they're both kind of >> troubling. > > The only thing I can think of is perhaps a hardware bug. MSI interrupts are > edge triggered while INTx are level. However, if a device implements MSI > by "listening" to the level-triggered interrupt and sending a message when > the level changes and it ever has a bug where it fails to send a message, > then it won't recover. FreeBSD doesn't do any masking of interrupts for MSI, > it just installs the handler in the IDT and calls it for every interrupt. > Thus, if you are not seeing interrupts it is likely not an issue with FreeBSD > itself, but an issue in the hardware (or possibly the driver if your > interrupt handler doesn't fully ACK something perhaps). With this hardware, failing to ACK would just cause a storm, which we'd see w/ INTx as well. But you are right about the possibility of a hardware issue--the particular piece we're testing right now has some other known issues as well. There's a linux driver that seems to work OK w/ MSIs, but they don't actually use hardware I2C and don't use interrupts there. This issue just needs more testing w/ more hardware, and we have a device hint to enable/disable MSIs anyway. > > -- > John Baldwin > From cyril.elkaim at free.fr Mon Feb 9 08:12:14 2009 From: cyril.elkaim at free.fr (cyril.elkaim@free.fr) Date: Mon Feb 9 08:12:21 2009 Subject: patch aoe for freebsd 7 In-Reply-To: <1306049302.637521234194665378.JavaMail.root@zimbra10-e2.priv.proxad.net> Message-ID: <124214240.637761234194728394.JavaMail.root@zimbra10-e2.priv.proxad.net> Hello there, Here you'll find an attached patch to compile the coraid aoe driver with freebsd 7. I'm not able to validate this driver myself, so if somebody can test it I will be very grateful. thanks, Cyril Elkaim -------------- next part -------------- A non-text attachment was scrubbed... Name: aoe7.patch Type: text/x-patch Size: 2908 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-drivers/attachments/20090209/a8cc28a1/aoe7.bin From jhb at freebsd.org Mon Feb 9 09:56:48 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Feb 9 09:56:56 2009 Subject: PCI-Express interrupt issues In-Reply-To: <2d1264630902090811p761b0a14w997985779aad8748@mail.gmail.com> References: <20090208113202.6d591589@CORONA> <200902090946.46917.jhb@freebsd.org> <2d1264630902090811p761b0a14w997985779aad8748@mail.gmail.com> Message-ID: <200902091254.06917.jhb@freebsd.org> On Monday 09 February 2009 11:11:20 am Jason Harmening wrote: > On Mon, Feb 9, 2009 at 8:46 AM, John Baldwin wrote: > > On Sunday 08 February 2009 12:32:02 pm Jason Harmening wrote: > >> Hi All, > >> > >> I'm the maintainer for the FreeBSD cx88 driver (multimedia/cx88). I've > >> recently encountered some issues w/ interrupt handling, specifically on > >> PCI-Express systems, and I was hoping someone would be able to help me. > >> > >> Issue #1: > >> > >> The cx88 driver has split interrupt handling between filters and > >> ithreads since filters became available w/ 7.0. For the past year, the > >> filters have been set up to return FILTER_SCHEDULE_THREAD if the status > >> register indicates an interrupt, FILTER_STRAY otherwise. Everything > >> has worked fine. > >> > >> However, I recently stumbled across some documentation indicating that > >> FILTER_SCHEDULE_THREAD shouldn't be returned alone--instead, the filter > >> should return FILTER_HANDLED | FILTER_SCHEDULE_THREAD. So I modified > >> the cx88 driver to do that instead, and that's where things turned > >> strange: > >> > >> On machine #1, which uses a VIA K8T800 chipset, everything still worked > >> fine. > >> > >> On machine #2, which uses a VIA K8T890 chipset, the threaded interrupt > >> handlers were no longer invoked. It's as though the bus driver saw > >> FILTER_HANDLED in the bitmask and assumed the interrupt was already > >> processed without checking to see if an ithread should be scheduled. > >> What's interesting is that the only significant difference between the > >> K8T800 in machine #1 and the K8T890 in machine #2 is that the K8T890 > >> supports PCI-Express, while the K8T800 is PCI-only. > > > > Are you seeing this only on 7.0? Also, do you have 'INTR_FILTER' enabled in > > the kernel? If you don't, then your ithread will never be called if you have > > a filter (actually, the bus_setup_intr() should fail in that case if you > > specify both). > > All machines are running 7.1-STABLE. Filters are enabled across the > board, and reverting to just returning FILTER_SCHEDULE_THREAD fixes > the issue. Do you see a dedicated interrupt thread for your device in top/ps? It should be 'intr: pcm0' (or whatever the device name is). -- John Baldwin From weongyo.jeong at gmail.com Tue Feb 10 04:31:30 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Tue Feb 10 04:31:50 2009 Subject: 8187SE driver In-Reply-To: References: <20090116040425.GB66457@freebsd.weongyo.org> <20090119101623.GC81329@freebsd.weongyo.org> <20090128103926.GA82455@freebsd.weongyo.org> Message-ID: <20090210123115.GA65828@weongyo.cdnetworks.kr> On Mon, Feb 09, 2009 at 04:04:07PM +0100, Jim Andersson wrote: > > > From: weongyo.jeong@gmail.com > > Date: Wed, 28 Jan 2009 19:39:26 +0900 > > To: freebsddog@hotmail.com > > CC: freebsd-drivers@freebsd.org > > Subject: Re: FW: 8187SE driver > > > > On Tue, Jan 27, 2009 at 02:23:33PM +0100, Jim Andersson wrote: > > > > > > From: freebsddog@hotmail.com > > > To: weongyo@freebsd.org > > > Subject: RE: 8187SE driver > > > Date: Tue, 27 Jan 2009 14:22:15 +0100 > > > > > > > From: weongyo.jeong@gmail.com > > > > Date: Mon, 19 Jan 2009 19:16:23 +0900 > > > > To: freebsddog@hotmail.com > > > > CC: freebsd-drivers@freebsd.org > > > > Subject: Re: 8187SE driver > > > > > > > > On Sat, Jan 17, 2009 at 04:16:43PM +0100, Jim Andersson wrote: > > > > > > > > > > > From: weongyo.jeong@gmail.com > > > > > > Date: Fri, 16 Jan 2009 13:04:26 +0900 > > > > > > To: freebsddog@hotmail.com > > > > > > CC: freebsd-drivers@freebsd.org > > > > > > Subject: Re: 8187SE driver > > > > > > > > > > > > On Thu, Jan 15, 2009 at 11:48:32AM +0100, Jim Andersson wrote: > > > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > Is there any chance of getting my wireless card running in > > > > > > > CURRENT. Linux says it???s a Realtek 8187SE wireless network > > > > > > > card. I have seen some driver for other 8187 cards, is it > > > > > > > possible to force such driver to try identify the card? > > > > > > > > > > > > > > > > > > > > > Here is the output of pciconf -lv in my FreeBSD > > > > > > > CURRENT:none1@pci0:1:0:0: class=0x028000 card=0x819910ec > > > > > > > chip=0x819910ec rev=0x22 hdr=0x00vendor = 'Realtek > > > > > > > Semiconductor'class = network . > > > > > > > > > > > > I think a thing you can try is that, NDISulator using ndis(4). AFAIK > > > > > > there's no support for 8187SE driver until now. > > > > > > > > > > > > regards, > > > > > > Weongyo Jeong > > > > > > > > > > > > > > > > I tried ndisulator but it didn?t work. I used the INF and the SYS > > > > > file for Windows Xp. I even tried including a cat file. > > > > > Although one thing changed, the card is no longer listed when i > > > > > type pciconf -lv. Dunno if that?s good or bad? > > > > > > > > It looks it's a bad news. Could you please show me dmesg's ouput and > > > > steps you followed? > > > > > > > > regards, > > > > Weongyo Jeong > > > > > > > > > > As far as I can see the only thing in dmesg regarding this card is: > > > > > > pci1: on pcib3 > > > pci1: at device 0.0 (no driver attached) > > > > > > What I did was this: I used my windows xp drivers for the card that I > > > recieved with the computer. I used the .sys and the inf file. The > > > driver loads good but no interface is shown. Is the someway to force > > > the driver to attach to pci2 somehow? > > > > Normally if it works well the device should be detected automatically > > and should show some messages related with ndis(4). It looks there are > > another problems in your case. BTW there's no way to force the driver > > to attach. > > > > > Or is there some way to use a linux driver? Linux says its a realtek > > > 8187SE. > > > > No way to use the linux driver. > > > > regards, > > Weongyo Jeong > > > > It seems there has been a recent release of a driver for MAC/OSX > according to this page: > > http://forums.msiwind.net/mac/great-news-regarding-rtl8187se-wifi-module-t3986.html > > perhaps I can persuade them into remaking a freebsd driver, Darwin is > not that far from BSD right? ;-) Yes. I think if we can see sources for MAC/OSX it'd could be portable to FreeBSD according to the license. However I tried to download a driver URL to see whether it includes sources. All I found was `Installer87se.pkg'; I can't mount .pkg file because I don't have a laptop Mac OS installed temporarily. regards, Weongyo Jeong From freebsddog at hotmail.com Thu Feb 12 05:18:14 2009 From: freebsddog at hotmail.com (Jim Andersson) Date: Thu Feb 12 05:18:23 2009 Subject: 8187SE driver In-Reply-To: <20090210123115.GA65828@weongyo.cdnetworks.kr> References: <20090116040425.GB66457@freebsd.weongyo.org> <20090119101623.GC81329@freebsd.weongyo.org> <20090128103926.GA82455@freebsd.weongyo.org> <20090210123115.GA65828@weongyo.cdnetworks.kr> Message-ID: > From: weongyo.jeong@gmail.com > Date: Tue, 10 Feb 2009 21:31:15 +0900 > To: freebsddog@hotmail.com > CC: freebsd-drivers@freebsd.org > Subject: Re: 8187SE driver > > On Mon, Feb 09, 2009 at 04:04:07PM +0100, Jim Andersson wrote: > > > > > From: weongyo.jeong@gmail.com > > > Date: Wed, 28 Jan 2009 19:39:26 +0900 > > > To: freebsddog@hotmail.com > > > CC: freebsd-drivers@freebsd.org > > > Subject: Re: FW: 8187SE driver > > > > > > On Tue, Jan 27, 2009 at 02:23:33PM +0100, Jim Andersson wrote: > > > > > > > > From: freebsddog@hotmail.com > > > > To: weongyo@freebsd.org > > > > Subject: RE: 8187SE driver > > > > Date: Tue, 27 Jan 2009 14:22:15 +0100 > > > > > > > > > From: weongyo.jeong@gmail.com > > > > > Date: Mon, 19 Jan 2009 19:16:23 +0900 > > > > > To: freebsddog@hotmail.com > > > > > CC: freebsd-drivers@freebsd.org > > > > > Subject: Re: 8187SE driver > > > > > > > > > > On Sat, Jan 17, 2009 at 04:16:43PM +0100, Jim Andersson wrote: > > > > > > > > > > > > > From: weongyo.jeong@gmail.com > > > > > > > Date: Fri, 16 Jan 2009 13:04:26 +0900 > > > > > > > To: freebsddog@hotmail.com > > > > > > > CC: freebsd-drivers@freebsd.org > > > > > > > Subject: Re: 8187SE driver > > > > > > > > > > > > > > On Thu, Jan 15, 2009 at 11:48:32AM +0100, Jim Andersson wrote: > > > > > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > > > Is there any chance of getting my wireless card running in > > > > > > > > CURRENT. Linux says it???s a Realtek 8187SE wireless network > > > > > > > > card. I have seen some driver for other 8187 cards, is it > > > > > > > > possible to force such driver to try identify the card? > > > > > > > > > > > > > > > > > > > > > > > > Here is the output of pciconf -lv in my FreeBSD > > > > > > > > CURRENT:none1@pci0:1:0:0: class=0x028000 card=0x819910ec > > > > > > > > chip=0x819910ec rev=0x22 hdr=0x00vendor = 'Realtek > > > > > > > > Semiconductor'class = network . > > > > > > > > > > > > > > I think a thing you can try is that, NDISulator using ndis(4). AFAIK > > > > > > > there's no support for 8187SE driver until now. > > > > > > > > > > > > > > regards, > > > > > > > Weongyo Jeong > > > > > > > > > > > > > > > > > > > I tried ndisulator but it didn?t work. I used the INF and the SYS > > > > > > file for Windows Xp. I even tried including a cat file. > > > > > > Although one thing changed, the card is no longer listed when i > > > > > > type pciconf -lv. Dunno if that?s good or bad? > > > > > > > > > > It looks it's a bad news. Could you please show me dmesg's ouput and > > > > > steps you followed? > > > > > > > > > > regards, > > > > > Weongyo Jeong > > > > > > > > > > > > > As far as I can see the only thing in dmesg regarding this card is: > > > > > > > > pci1: on pcib3 > > > > pci1: at device 0.0 (no driver attached) > > > > > > > > What I did was this: I used my windows xp drivers for the card that I > > > > recieved with the computer. I used the .sys and the inf file. The > > > > driver loads good but no interface is shown. Is the someway to force > > > > the driver to attach to pci2 somehow? > > > > > > Normally if it works well the device should be detected automatically > > > and should show some messages related with ndis(4). It looks there are > > > another problems in your case. BTW there's no way to force the driver > > > to attach. > > > > > > > Or is there some way to use a linux driver? Linux says its a realtek > > > > 8187SE. > > > > > > No way to use the linux driver. > > > > > > regards, > > > Weongyo Jeong > > > > > > > It seems there has been a recent release of a driver for MAC/OSX > > according to this page: > > > > http://forums.msiwind.net/mac/great-news-regarding-rtl8187se-wifi-module-t3986.html > > > > perhaps I can persuade them into remaking a freebsd driver, Darwin is > > not that far from BSD right? ;-) > > Yes. I think if we can see sources for MAC/OSX it'd could be portable > to FreeBSD according to the license. > > However I tried to download a driver URL to see whether it includes > sources. All I found was `Installer87se.pkg'; I can't mount .pkg file > because I don't have a laptop Mac OS installed temporarily. > > regards, > Weongyo Jeong > great I have contacted them to see if we can look at the source code dunno what they feel about that :-) _________________________________________________________________ 25 GB gratis lagring p? n?tet - Skaffa SkyDrive nu! http://skydrive.live.com From gibblertron at gmail.com Mon Feb 16 23:14:07 2009 From: gibblertron at gmail.com (patrick) Date: Mon Feb 16 23:14:13 2009 Subject: Porting a 5.3 USB WLAN driver to 7.1 Message-ID: I'm doing my best to port a driver (atuwi) for a Linksys WUSB11v2.8 driver that was written for FreeBSD 5.x to 7.1, but as I'm not a kernel hacker by any means, I'm having a few problems. I've managed to update Daan Vreeken's atuwi so that it compiles and loads, but I haven't yet got it to connect to my wireless network. When I load driver, I get a couple warnings: atuwi0: WARNING: using obsoleted if_watchdog interface atuwi0: WARNING: using obsoleted IFF_NEEDSGIANT flag I've Googled both messages, but haven't found any discussion on when these were obsoleted and what you're supposed to do instead. My ifconfig status shows up as: atuwi0: flags=108802 metric 0 mtu 1500 ether 00:0c:41:5a:48:5f inet 10.0.42.223 netmask 0xffffff00 broadcast 10.0.42.255 maclabel ?biba,?lomac,?mls,?sebsd media: IEEE 802.11 Wireless Ethernet autoselect status: no carrier vlan: 0 parent interface: ifconfig: unable to get channel information ssid "Air Mousey" I notice that "status" shows up as "no carrier", and I'm not sure what exactly that means and why it's unable to get any "channel information". I also notice question marks in the "maclabel" line, and I suspect that might be indicative of a problem. My biggest problem is that I can't find any documentation on the "right" way to structure such a driver. I've looked at other if_xxxx drivers in the usb/ folder, but each does its thing in its own way. Both OpenBSD and NetBSD adopted Daan's atuwi driver and have had it running for a while, but unfortunately no one in the FreeBSD world took it on. If anyone has any insight or can point me in the right direction, I'd be greatly appreciative. Thanks, Patrick From huntting at glarp.com Sat Feb 21 12:37:21 2009 From: huntting at glarp.com (Brad Huntting) Date: Sat Feb 21 12:37:27 2009 Subject: kernel gdb over Ethernet Message-ID: I'm thinking about how to implement gdb over Ethernet (or UDP or TCP). I know this has been considered in the past by several different people, and it's even been implemented in Linux (which makes the gdb(1) end simpler). My idea was to create a netgraph node that can act as a gdb stub. Then poll the network interface(s) from the gdb_getc() loop to read data. But, before I go much further, has this already been implemented somewhere and I'm just not finding it? brad From clamav at citromail.hu Sun Feb 22 00:27:12 2009 From: clamav at citromail.hu (Tesch Zoltan) Date: Sun Feb 22 00:27:18 2009 Subject: debugging network device driver Message-ID: <20090222080029.3900.qmail@server23.citromail.hu> Hi, I have just tried to port SiS190 Linux driver to FreebBSD. It seems to me that this driver looks like r8169 and for this reason my port is based on the "re" device driver of FreeBSD 6.4. I can load the module, attach to SiS190 device, miibus and phy but when I try to set up the interface with ifconfig (ifconfig sis0 up) the computer freezes. I have tried to print status information from my driver (using printf`s in the code) but the last record in the log is that miibus_readreg returned a good value, no other record is logged into the system log. My questions: Is there any way to switch to kernel debug mode in this situation to see what happened or is it possible to run the module under the supervision of kernel debugger running on the machine, because this laptop has no serial line or any other network interface. Thanks Zoltan From pyunyh at gmail.com Sun Feb 22 17:20:13 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sun Feb 22 17:20:19 2009 Subject: debugging network device driver In-Reply-To: <20090222080029.3900.qmail@server23.citromail.hu> References: <20090222080029.3900.qmail@server23.citromail.hu> Message-ID: <20090223005416.GC48134@michelle.cdnetworks.co.kr> On Sun, Feb 22, 2009 at 09:00:29AM +0100, Tesch Zoltan wrote: > Hi, > > I have just tried to port SiS190 Linux driver to FreebBSD. It seems to > me that this driver looks like r8169 and for this reason my port is > based on the "re" device driver of FreeBSD 6.4. Hmm, I have no idea why SiS190 is similar to RTL8169. Both controllers have small set of registers though. > I can load the module, attach to SiS190 device, miibus and phy but when > I try to set up the interface with ifconfig (ifconfig sis0 up) the > computer freezes. I have tried to print status information from my > driver (using printf`s in the code) but the last record in the log is > that miibus_readreg returned a good value, no other record is logged > into the system log. > It's hard to say what was wrong here. Datasheet is not available to open source developers and the controller seem to have severe alignment restrictions as well as lack of auto-padding. > My questions: > Is there any way to switch to kernel debug mode in this situation to see > what happened or is it possible to run the module under the supervision > of kernel debugger running on the machine, because this laptop has no > serial line or any other network interface. > ktr(4) is much better than printfs. Btw there was a post for SiS190 driver so you can reference his work. http://lists.freebsd.org/pipermail/freebsd-drivers/2008-April/000685.html Having a wired/wireless USB network controller would make your life easier. From clamav at citromail.hu Mon Feb 23 11:40:09 2009 From: clamav at citromail.hu (Tesch Zoltan) Date: Mon Feb 23 11:40:22 2009 Subject: debugging network device driver In-Reply-To: <20090223005416.GC48134@michelle.cdnetworks.co.kr> Message-ID: <20090223194005.12142.qmail@server23.citromail.hu> Hi, Thanx a lot, I will try it Zoltan -- Eredeti ?zenet -- Felad?: Pyun YongHyeon <pyunyh@gmail.com> C?mzett: Tesch Zoltan <clamav@citromail.hu> Elk?ldve: 01:49 T?ma: Re: debugging network device driver On Sun, Feb 22, 2009 at 09:00:29AM +0100, Tesch Zoltan wrote: > Hi, > > I have just tried to port SiS190 Linux driver to FreebBSD. It seems to > me that this driver looks like r8169 and for this reason my port is > based on the "re" device driver of FreeBSD 6.4. Hmm, I have no idea why SiS190 is similar to RTL8169. Both controllers have small set of registers though. > I can load the module, attach to SiS190 device, miibus and phy but when > I try to set up the interface with ifconfig (ifconfig sis0 up) the > computer freezes. I have tried to print status information from my > driver (using printf`s in the code) but the last record in the log is > that miibus_readreg returned a good value, no other record is logged > into the system log. > It's hard to say what was wrong here. Datasheet is not available to open source developers and the controller seem to have severe alignment restrictions as well as lack of auto-padding. > My questions: > Is there any way to switch to kernel debug mode in this situation to see > what happened or is it possible to run the module under the supervision > of kernel debugger running on the machine, because this laptop has no > serial line or any other network interface. > ktr(4) is much better than printfs. Btw there was a post for SiS190 driver so you can reference his work. http://lists.freebsd.org/pipermail/freebsd-drivers/2008-April/000685.html Having a wired/wireless USB network controller would make your life easier. From gkpect at gmail.com Wed Feb 25 06:27:00 2009 From: gkpect at gmail.com (Stanislav Bondarenko) Date: Wed Feb 25 06:56:52 2009 Subject: Samsung SWC-U200 Message-ID: <65aa157b0902250614g367f1440y6e11c9e84a702aaf@mail.gmail.com> Hello, Is there any possibility to work with this modem in FreeBSD? From gkpect at gmail.com Thu Feb 26 04:03:57 2009 From: gkpect at gmail.com (Stanislav Bondarenko) Date: Thu Feb 26 04:04:04 2009 Subject: Samsung SWC-U200 In-Reply-To: <65aa157b0902250614g367f1440y6e11c9e84a702aaf@mail.gmail.com> References: <65aa157b0902250614g367f1440y6e11c9e84a702aaf@mail.gmail.com> Message-ID: <65aa157b0902260403i3d3c1ccbvf0e4a5bb3a982058@mail.gmail.com> This is WiMax modem. Some additional information can be found here: http://www.wimaxforum.org/productshowcase/samsungswcu200 Also I've found Russian project about driver for Linux. It contains information about protocol and requests used by modem. Unfortunately, I can't find the same project in English. http://code.google.com/p/madwimax/