Re: BUS_SPACE_MAXSIZE isp driver.
I think it should go away. We should malloc space to hold the segments in the leaf dma tags and base that size on the information in the tag. The segments would only be allocated on the first dma_map_create call on a tag so that intermediate (i.e. non-leaf) tags never have this stuff allocate d. But lacking that, what does it mean? Nothing. The maximum mapping size is in the tag. tag create calls can fail, so if the tag creation request is too large, the port's tag creation call should fail. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
For ISA, this ends up being a 16M limit; I think the 2G limit on Alpha is because the limit is 32 bits, but there is some signed math that should be unsigned. No, Terry, it has to do with the PCI bridge's translation mapping hardware, and if we supported it (which we don't seem to) then the problem would all just go away. Please, give up with the guessing already. 8) -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
Now, Mike, play nice... On Fri, 5 Apr 2002, Michael Smith wrote: For ISA, this ends up being a 16M limit; I think the 2G limit on Alpha is because the limit is 32 bits, but there is some signed math that should be unsigned. No, Terry, it has to do with the PCI bridge's translation mapping hardware, and if we supported it (which we don't seem to) then the problem would all just go away. Please, give up with the guessing already. 8) -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
BUS_SPACE_MAXSIZE isp driver.
I just booted a recent current (or rather attempted to) and saw this when attempting to mount root from a qlogic card on my miata: bus_dmamap_load: Too many segs! buf_len = 0x2000 spec_getpages:(da0a) I/O read failure: (error=22) bp 0xfe0004087ae8 vp 0xfe000ae9 size: 98304, resid: 98304, a_count: 98304, valid: 0x0 nread: 0, reqpage: 7, pindex: 59, pcount: 12 vm_fault: pager read error, pid 1 (init) ... more of same ... The only way I could get the system to boot was to increase BUS_SPACE_MAXSIZE to 128K to match MAXPHYS. I don't know why they don't match in the first place (they don't match on x86 either, so the driver will probably puke there too.) #define BUS_SPACE_MAXSIZE(128 * 1024) Does anybody know why BUS_SPACE_MAXSIZE != MAXPHYS on some platforms? Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
Ah- this bit Marcel with FreeBSD-ia64 too. I hadn't gotten too that. I haven't tried it yet in i386. Worked for in Alpha Sparc64, but I guess it didn't work for all alphas. I just reinstalled 5.0 and will be trying an i386 kernel shortly. It would seem to me you can't have BUS_SPACE_MAXSIZE less than MAXPHYS- that seems absurd to me. What happened here is that in trying to make isp work for sparc64, I redid the usage of bus_dma. Since the author never finished man pages or wrote up a spec, the implementations (and architecture) is open to interpretation. -matt On Thu, 4 Apr 2002, Andrew Gallatin wrote: I just booted a recent current (or rather attempted to) and saw this when attempting to mount root from a qlogic card on my miata: bus_dmamap_load: Too many segs! buf_len = 0x2000 spec_getpages:(da0a) I/O read failure: (error=22) bp 0xfe0004087ae8 vp 0xfe000ae9 size: 98304, resid: 98304, a_count: 98304, valid: 0x0 nread: 0, reqpage: 7, pindex: 59, pcount: 12 vm_fault: pager read error, pid 1 (init) ... more of same ... The only way I could get the system to boot was to increase BUS_SPACE_MAXSIZE to 128K to match MAXPHYS. I don't know why they don't match in the first place (they don't match on x86 either, so the driver will probably puke there too.) #define BUS_SPACE_MAXSIZE(128 * 1024) Does anybody know why BUS_SPACE_MAXSIZE != MAXPHYS on some platforms? Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
Matthew Jacob writes: Ah- this bit Marcel with FreeBSD-ia64 too. I hadn't gotten too that. I haven't tried it yet in i386. Worked for in Alpha Sparc64, but I guess it didn't work for all alphas. I just reinstalled 5.0 and will be trying an i386 kernel shortly. It would seem to me you can't have BUS_SPACE_MAXSIZE less than MAXPHYS- that seems absurd to me. Me too. I was about to just change it for alpha, but then I wondered if there was a reason for having BUS_SPACE_MAXSIZE MAXPHYS. I've CC'ed Justin. I think he was the original author, perhaps he can enlighten us. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
Actually, I suppose if you change: #define ISP_NSEG((MAXPHYS/PAGE_SIZE) + 1) to #define ISP_NSEG((BUS_SPACE_MAXSIZE/PAGE_SIZE) + 1) this will probably be more correct. I think this is probably what I should be using anyway. BTW- this was more of a 'hackers' or 'scsi' issue. I *used* to, btw, put a massively large number for segments- basically the max *should* be the number of segments I can stick in a single Request Queue (2 or 3) command plus all the continuation entries possible (5 or 7 per continuation entries, for FreeBSD ~250 or so- MMV depending on current state)- that'd be on the order of ~1800 segments. After getting burned by some surprises in the sparc64 implementation, I decided to restrict it to paramaters that were compile time invariants for each platform. I guess I picked the wrong parameter :-). -matt On Thu, 4 Apr 2002, Andrew Gallatin wrote: I just booted a recent current (or rather attempted to) and saw this when attempting to mount root from a qlogic card on my miata: bus_dmamap_load: Too many segs! buf_len = 0x2000 spec_getpages:(da0a) I/O read failure: (error=22) bp 0xfe0004087ae8 vp 0xfe000ae9 size: 98304, resid: 98304, a_count: 98304, valid: 0x0 nread: 0, reqpage: 7, pindex: 59, pcount: 12 vm_fault: pager read error, pid 1 (init) ... more of same ... The only way I could get the system to boot was to increase BUS_SPACE_MAXSIZE to 128K to match MAXPHYS. I don't know why they don't match in the first place (they don't match on x86 either, so the driver will probably puke there too.) #define BUS_SPACE_MAXSIZE(128 * 1024) Does anybody know why BUS_SPACE_MAXSIZE != MAXPHYS on some platforms? Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
Oops. That wasn't it. Taking this offline. On Thu, 4 Apr 2002, Matthew Jacob wrote: Actually, I suppose if you change: #define ISP_NSEG((MAXPHYS/PAGE_SIZE) + 1) to #define ISP_NSEG((BUS_SPACE_MAXSIZE/PAGE_SIZE) + 1) this will probably be more correct. I think this is probably what I should be using anyway. BTW- this was more of a 'hackers' or 'scsi' issue. I *used* to, btw, put a massively large number for segments- basically the max *should* be the number of segments I can stick in a single Request Queue (2 or 3) command plus all the continuation entries possible (5 or 7 per continuation entries, for FreeBSD ~250 or so- MMV depending on current state)- that'd be on the order of ~1800 segments. After getting burned by some surprises in the sparc64 implementation, I decided to restrict it to paramaters that were compile time invariants for each platform. I guess I picked the wrong parameter :-). -matt On Thu, 4 Apr 2002, Andrew Gallatin wrote: I just booted a recent current (or rather attempted to) and saw this when attempting to mount root from a qlogic card on my miata: bus_dmamap_load: Too many segs! buf_len = 0x2000 spec_getpages:(da0a) I/O read failure: (error=22) bp 0xfe0004087ae8 vp 0xfe000ae9 size: 98304, resid: 98304, a_count: 98304, valid: 0x0 nread: 0, reqpage: 7, pindex: 59, pcount: 12 vm_fault: pager read error, pid 1 (init) ... more of same ... The only way I could get the system to boot was to increase BUS_SPACE_MAXSIZE to 128K to match MAXPHYS. I don't know why they don't match in the first place (they don't match on x86 either, so the driver will probably puke there too.) #define BUS_SPACE_MAXSIZE(128 * 1024) Does anybody know why BUS_SPACE_MAXSIZE != MAXPHYS on some platforms? Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
Andrew Gallatin wrote: Me too. I was about to just change it for alpha, but then I wondered if there was a reason for having BUS_SPACE_MAXSIZE MAXPHYS. From what I understand, the Alpha is limited to doing transfers in the first 2G of memory. I'm not sure if the ISA 16M memory limit is in there anywhere, either. The problem is that a DMA initiated by a bus mastering device can only access as many bis of address space as are passed through the bus, end-to-end. For ISA, this ends up being a 16M limit; I think the 2G limit on Alpha is because the limit is 32 bits, but there is some signed math that should be unsigned. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
On Thu, 4 Apr 2002, Terry Lambert wrote: Andrew Gallatin wrote: Me too. I was about to just change it for alpha, but then I wondered if there was a reason for having BUS_SPACE_MAXSIZE MAXPHYS. From what I understand, the Alpha is limited to doing transfers in the first 2G of memory. I'm not sure if the ISA 16M memory limit is in there anywhere, either. The problem is that a DMA initiated by a bus mastering device can only access as many bis of address space as are passed through the bus, end-to-end. For ISA, this ends up being a 16M limit; I think the 2G limit on Alpha is because the limit is 32 bits, but there is some signed math that should be unsigned. Neither is really applicable here. The actual limits for alpha depend on the platforma and how you implement it. Typically, the bigger alphas have been implemented with a 2GB direct mapped window, and then, if they have it, a S/G map setup for the rest (if any) of memory, which also can include ISA mapping. The current Alpha 2.4.18 Linux implementation is quite happy to DMA to 4GB on quite a few alphas. BUS_SPACE_MAXSIZE seems to be related to the 'largest xfer you will be allowed to do at one time'- which is wrong because MAXPHYS is larger. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
Matthew Jacob wrote: Neither is really applicable here. The actual limits for alpha depend on the platforma and how you implement it. Typically, the bigger alphas have been implemented with a 2GB direct mapped window, and then, if they have it, a S/G map setup for the rest (if any) of memory, which also can include ISA mapping. Thanks for the clarification. I was confusing BUS_SPACE_MAXSIZE with BUS_SPACE_MAXSIZE_24BIT and BUS_SPACE_MAXSIZE_32BIT. It's probably too late to rename BUS_SPACE_MAXSIZE to something like BUS_SPACE_MAXXFER. 8-(. The current Alpha 2.4.18 Linux implementation is quite happy to DMA to 4GB on quite a few alphas. Ah. Reference code. BUS_SPACE_MAXSIZE seems to be related to the 'largest xfer you will be allowed to do at one time'- which is wrong because MAXPHYS is larger. Yeah, I get that now. No need to beat me up, I can take care of it myself. 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
On Thu, 4 Apr 2002, Terry Lambert wrote: Matthew Jacob wrote: Neither is really applicable here. The actual limits for alpha depend on the platforma and how you implement it. Typically, the bigger alphas have been implemented with a 2GB direct mapped window, and then, if they have it, a S/G map setup for the rest (if any) of memory, which also can include ISA mapping. Thanks for the clarification. I was confusing BUS_SPACE_MAXSIZE with BUS_SPACE_MAXSIZE_24BIT and BUS_SPACE_MAXSIZE_32BIT. It's probably too late to rename BUS_SPACE_MAXSIZE to something like BUS_SPACE_MAXXFER. 8-(. Yes. If we've understood it at all. There are no documents really describing it. The current Alpha 2.4.18 Linux implementation is quite happy to DMA to 4GB on quite a few alphas. Ah. Reference code. BUS_SPACE_MAXSIZE seems to be related to the 'largest xfer you will be allowed to do at one time'- which is wrong because MAXPHYS is larger. Yeah, I get that now. No need to beat me up, I can take care of it myself. 8-) 8-). No, no at least you showed some interest :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
Matthew Jacob wrote: Thanks for the clarification. I was confusing BUS_SPACE_MAXSIZE with BUS_SPACE_MAXSIZE_24BIT and BUS_SPACE_MAXSIZE_32BIT. It's probably too late to rename BUS_SPACE_MAXSIZE to something like BUS_SPACE_MAXXFER. 8-(. Yes. If we've understood it at all. There are no documents really describing it. I was going to mention this, but I censured myself so that it wouldn't look like I was whinging... 8-) 8-). The documentation in these areas is atrocious. There needs to be a documentation requirement for the commit of huge things, like bus space, CAM, devfs, GEOM, etc. ... BUS_SPACE_MAXSIZE seems to be related to the 'largest xfer you will be allowed to do at one time'- which is wrong because MAXPHYS is larger. Yeah, I get that now. No need to beat me up, I can take care of it myself. 8-) 8-). No, no at least you showed some interest :-) If that's supposed to trick me into doing the missing documentation, it's not working... 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
BUS_SPACE_MAXSIZE seems to be related to the 'largest xfer you will be allowed to do at one time'- which is wrong because MAXPHYS is larger. If you look at the x86 implementation, BUS_SPACE_MAXSIZE is only used in the non-GNUC case and is not referenced (I don't think) by any driver code. Even setting it to MAXPHYS is not truely correct since at some point we will have to start supporting transfer mappings that are larger than what can be mapped by a single buffer. I never realized that there was such controversy over this value... it was just put in so that I could have something for the non-GNUC case. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
On Thu, 4 Apr 2002, Justin T. Gibbs wrote: BUS_SPACE_MAXSIZE seems to be related to the 'largest xfer you will be allowed to do at one time'- which is wrong because MAXPHYS is larger. If you look at the x86 implementation, BUS_SPACE_MAXSIZE is only used in the non-GNUC case and is not referenced (I don't think) by any driver code. Even setting it to MAXPHYS is not truely correct since at some point we will have to start supporting transfer mappings that are larger than what can be mapped by a single buffer. I never realized that there was such controversy over this value... it was just put in so that I could have something for the non-GNUC case. Yeah, but, uh, it'll blow up in one's face. The question I have is what *should* we be using? Should BUS_SPACE_MAXSIZE be bumped up so that any dma allocation we attempt for a platform will fit within it? I mean, it's used in a lot of places, so clearly it must mean something, right? What are the semantics here? -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
a single buffer. I never realized that there was such controversy over this value... it was just put in so that I could have something for the non-GNUC case. Yeah, but, uh, it'll blow up in one's face. If it gets compiled, I suppose so. The question I have is what *should* we be using? Should BUS_SPACE_MAXSIZE be bumped up so that any dma allocation we attempt for a platform will fit within it? I think it should go away. We should malloc space to hold the segments in the leaf dma tags and base that size on the information in the tag. The segments would only be allocated on the first dma_map_create call on a tag so that intermediate (i.e. non-leaf) tags never have this stuff allocated. I mean, it's used in a lot of places, so clearly it must mean something, right? What are the semantics here? Is it really used in a lot of places? I've always used the bit sized versions of MAXSIZE in my driver code, never the ambiguous one. 8-) -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BUS_SPACE_MAXSIZE isp driver.
On Thu, 4 Apr 2002, Justin T. Gibbs wrote: a single buffer. I never realized that there was such controversy over this value... it was just put in so that I could have something for the non-GNUC case. Yeah, but, uh, it'll blow up in one's face. If it gets compiled, I suppose so. The question I have is what *should* we be using? Should BUS_SPACE_MAXSIZE be bumped up so that any dma allocation we attempt for a platform will fit within it? I think it should go away. We should malloc space to hold the segments in the leaf dma tags and base that size on the information in the tag. The segments would only be allocated on the first dma_map_create call on a tag so that intermediate (i.e. non-leaf) tags never have this stuff allocated. But lacking that, what does it mean? I mean, it's used in a lot of places, so clearly it must mean something, right? What are the semantics here? Is it really used in a lot of places? About 40 files. But everyone has copied them. I've always used the bit sized versions of MAXSIZE in my driver code, never the ambiguous one. 8-) -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
