您好！
现为您提供外方以现汇投入、中方以土地、厂房、设施等折价投入、产品外销的中外合资项目，望速联系。
名贵兰花栽培项目 三实总：30851583
总投资：100万美元；注册资金：80万美元；
投资比例：外方60%，中方40%；外方以现汇投入，中方以现有场地及水、电等配套设施投入（现有大棚最佳）；种值面积：大棚13000平方（20亩）；年利润：约500万元人民币；合资年限：20年；产品100%外销。
中外合资（多烯脂肪酸）鱼油项目
Title: Untitled Document
Поздравляем
ВАС с наступающими зимними Праздниками!
Успехов и процветания в Новом году!
On Sat, Nov 27, 2004 at 05:35:58PM -0800, Pete Zaitcev wrote:
> Hi, Greg, hi, guys:
>
> Here's what I'd like to see in current round of 2.4 with Marcelo.
> A few problems were addressed:
Looks good to me, thanks for doing this work.
thanks,
greg k-h
---
On Wed, Dec 15, 2004 at 04:47:37PM -0800, Pete Zaitcev wrote:
> On Wed, 15 Dec 2004 16:01:43 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
>
> > > When a USB serial device is disconnected, user applications performing a
> > > read() now receive an error code, rather than waiting indefinitely.
>
> >
On Sat, Nov 27, 2004 at 04:47:40PM -0800, Pete Zaitcev wrote:
> I would like to clean up mct_u232 a little bit, although primarily to make
> my fixes to 2.4 branch look better. The attached patch does this:
> - zeroes whole private structure
> - zaps dangling pointer (or why do we check it then)
On Friday 17 December 2004 3:25 pm, Robert Wruck wrote:
> > At which point an "alt-sysrq-t" traceback should be informative,
> > if this patch doesn't help the latest rc3-BK code.
>
> Thanks! Keeping the root hub from suspending seems to solve the
> problem..
Good -- it's already in 2.6.10-rc3-b
On Fri, Dec 17, 2004 at 05:14:34PM -0500, Alan Stern wrote:
> Greg:
>
> Here's the patch to make dummy_hcd build properly once again. I did some
> quick light testing to make sure that it still works too. The patch takes
> the easy way out by allocating a new private data structure for each URB,
On Thu, Dec 09, 2004 at 09:40:45PM +0100, Hermann Kneissel wrote:
> Sorry,
>
> here's the patch.
Thanks, I've applied this to my trees, along with a small patch that
fixed up some warnings found by sparse.
greg k-h
---
SF email is sponsored b
> At which point an "alt-sysrq-t" traceback should be informative,
> if this patch doesn't help the latest rc3-BK code.
Thanks! Keeping the root hub from suspending seems to solve the
problem..
-robert
---
SF email is sponsored by - The IT P
On Friday 17 December 2004 2:21 pm, Jean-Christophe Le Lann wrote:
> I have a serious bug on my Fedora core 3 (kernel 2.6.9-1.681_FC3), when
For distro kernels, contract the distro folk ... but in this case,
I suspect you'd find 2.6.10-rc3-bk resolves this.
Hi !
I have a serious bug on my Fedora core 3 (kernel 2.6.9-1.681_FC3), when
plugging my USB key (lexar), but same applies for my USB printer(epson
cx 5200). They were both working fine on FC1. My card is asustech k7m,
Athlon 550Mhz. Don't know more.
I have been told to send this message here, an
Greg:
Here's the patch to make dummy_hcd build properly once again. I did some
quick light testing to make sure that it still works too. The patch takes
the easy way out by allocating a new private data structure for each URB,
just to keep a single united list of all the outstanding URBs. More
On Fri, Dec 17, 2004 at 08:02:45AM -0800, David Brownell wrote:
> Greg, this patch is worth putting into your 2.6.11 queue.
> It needs testing like it'd get in the MM tree first, but
> preliminary reports are that it behaves as intended.
>
> It's exactly what I sent last week (modulo slightly upda
- Original Message -
From: "jeanseb valette" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Friday, December 17, 2004 7:55 PM
Subject: Re: [linux-usb-devel] Re: [ECI] linux-2.4.28 broke eciadsl-sync
> in devio.c the usb core dow two semaphore
On Thu, 16 Dec 2004, Robert Hoffler wrote:
> I'm attaching the output from 'cat
> /proc/bus/usb/devices'. When I ran this command, I
> had a 2-port USB hub plugged into 1 of the 4 usb ports
> on the notebook. Also, I had a USB optical mouse
> plugged into the 2-port hub. Here's what I've
> noti
in devio.c the usb core dow two semaphore the switch on cmd.
In case of USBDEVFS_CONTROL it call proc_control then proc_internal_control
which call usb_control_mesage then we go in usb_start_wait_urb which
set_current_state(TASK_UNINTERRUPTIBLE);.
But semaphore are still down so next urb sen
On Tue, 7 Dec 2004, David Brownell wrote:
> I think it might be a good idea to try out a cleaned-up
> version of this patch more widely.
Here's a cleaned-up patch that does what you wanted, plus a little more.
Its main feature is that the patch does a USB port reset whenever there's
a transpor
I recently ran up against a scenario in which khubd was awakened and
started interfering during a port reset. (Don't ask me why this has never
turned up before.) Although this was a possibility I had considered some
time ago, no protections were ever added to the kernel to deal with it.
Anyway,
Hi Michael,
Michael writes:
> Thanks for your responses, guys.
> I worked around the problem by increasing the INT buffer's blk
> size:
>
> // dev->intl_queue.num_bufs = 32;
> // dev->intl_queue.blk_size = 8;
> dev->intl_queue.num_bufs = 1;
>
--- Lothar Wassmann <[EMAIL PROTECTED]> wrote:
> Hi David,
>
> > On Friday 17 December 2004 6:53 am, Lothar Wassmann wrote:
> > > Hi David,
> > >
> > > > On Friday 17 December 2004 1:51 am, Lothar Wassmann wrote:
> > > > > > xfer_size = ptd_xfer_size(ptd_q, xfer_type, len);
> > > > > > printk
On Friday 17 December 2004 7:49 am, li xinyi wrote:
> I can understand DMA buffer initlisation for EDs and TDs. But, in my
> case I am working for OHCI connecting to ARM AHB bus with a seperate
> general purpose DMA controller connecting to AHB as well.
You'll be ignoring that completely, unless y
Greg, this patch is worth putting into your 2.6.11 queue.
It needs testing like it'd get in the MM tree first, but
preliminary reports are that it behaves as intended.
It's exactly what I sent last week (modulo slightly updated
patch comments), so it applies with a bit of fuzz to your
latest BK.
> That's what _enables_ PCI bus-mastering (DMA) by the device.
>
> OHCI controllers do memory accesses all the time, as normal
> part of operation. They have some registers that point to
> memory locations for the USB transaction schedule, and every
> millisecond they start scanning that schedule
On Friday 10 December 2004 2:48 am, Tom Rathbone wrote:
>
> Could this please be added to gadget_chips.h:
>
> +#ifdef CONFIG_USB_GADGET_AT91RM9200
> +#define gadget_is_at91rm9200(g) !strcmp("at91rm9200_udc", (g)->name)
> +#else
> +#define gadget_is_at91rm9200(g) 0
> +#endif
Sure, but i
Hi David,
> On Friday 17 December 2004 6:53 am, Lothar Wassmann wrote:
> > Hi David,
> >
> > > On Friday 17 December 2004 1:51 am, Lothar Wassmann wrote:
> > > > > xfer_size = ptd_xfer_size(ptd_q, xfer_type, len);
> > > > > printk("len = %d, xfer_size = %d, mps = %d, xfer_type = %d\n",
> > > >
Hi Lothar,
On Friday 17 December 2004 6:53 am, Lothar Wassmann wrote:
> Hi David,
>
> > On Friday 17 December 2004 1:51 am, Lothar Wassmann wrote:
> > > > xfer_size = ptd_xfer_size(ptd_q, xfer_type, len);
> > > > printk("len = %d, xfer_size = %d, mps = %d, xfer_type = %d\n",
> > > > len, xfer_s
This patch brings up to date the cypress_m8 driver with the latest
development tree. It reorganizes some code and addresses a few issues
brought up on this list.
-Added MODULE_VERSION macro
-Implemented Al Borchers pl2303 circular write buffer and features.
-Fixed bug with RTS being dropped upo
Hi David,
> On Friday 17 December 2004 1:51 am, Lothar Wassmann wrote:
> > > xfer_size = ptd_xfer_size(ptd_q, xfer_type, len);
> > > printk("len = %d, xfer_size = %d, mps = %d, xfer_type = %d\n",
> > > len, xfer_size, mps, xfer_type);
> > > if (xfer_size < len && xfer_size % mps) {
> > >
On Friday 17 December 2004 1:51 am, Lothar Wassmann wrote:
> > xfer_size = ptd_xfer_size(ptd_q, xfer_type, len);
> > printk("len = %d, xfer_size = %d, mps = %d, xfer_type = %d\n",
> > len, xfer_size, mps, xfer_type);
> > if (xfer_size < len && xfer_size % mps) {
> > BUG_ON(xfer_size < m
Am Freitag, 17. Dezember 2004 14:33 schrieb li xinyi:
> > >
> > > which piece of code initiated the DMA?
> >
> > I am not a specialist on ohci, but have a look at ohci_hub_resume()
> >
>
> I can not find explicit code which initialises DMA. Could it be
> pci_set_master?
pci_set_master() indeed
> >
> > which piece of code initiated the DMA?
>
> I am not a specialist on ohci, but have a look at ohci_hub_resume()
>
I can not find explicit code which initialises DMA. Could it be pci_set_master?
> It dispatches among the drivers sharing a major number, but you are
> not required to use
Am Freitag, 17. Dezember 2004 12:16 schrieb li xinyi:
> >
> > The hci walks its lists on its own. DMA is initiated once and then
> > the hci works on its schedule which is described by descriptors in ram
> > which is read by DMA.
>
> which piece of code initiated the DMA?
I am not a specialist o
>
> The hci walks its lists on its own. DMA is initiated once and then
> the hci works on its schedule which is described by descriptors in ram
> which is read by DMA.
which piece of code initiated the DMA?
>
> PCI devices implement DMA on their own. Their is no equivalent to
> the ISA DMA con
Hi Michael,
> Hi. I'm using the ohci-isp1362 driver, and I'm finally getting it
> working. However, I can make it crash every time I use a
> usb-serial adapter.
>
> I seem to trigger the BUG_ON(xfer_size < mps) in process_td.
> (ohci-isp1362-emu.c) It seems the null pointer dereference is
> cau
On Fri, 17 Dec 2004, li xinyi wrote:
> Hi, all
>
> Here is two questions about USB drvier in kernel 2.4.20
>
> 1. In the usb-ohci.c, buffer for TD is allocated as below:
It isn't allocated. It is mapped into the hci's space.
> data = pci_map_single (ohci->ohci_dev,
>
Hi, all
Here is two questions about USB drvier in kernel 2.4.20
1. In the usb-ohci.c, buffer for TD is allocated as below:
data = pci_map_single (ohci->ohci_dev,
urb->transfer_buffer, data_len,
usb_pipeout (urb->pipe)
36 matches
Mail list logo
