> To conclude, the store the *last* N bytes received seems a more
> reasonable policy for the input buffers managed by the kernel. If the
For your use maybe, but it is not the normal behaviour and it is not the
behaviour supported by hardware, which generally buffers the first few
bytes (and some
> However, whatever policy the buffer uses, the fundamental point it's that
> when I flush the input buffer I should be sure that each byte read
> after the flush is *new* (current) data and not old one. This because
Define "new" and "old" in this case. I don't believe you can give a
precise defin
On Sat, 5 May 2007 20:07:15 +0200
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Samstag, 5. Mai 2007 18:36 schrieb Alan Cox:
> > > In the serial driver this usually just results in dropping
> > > RTS to signal the remote end to stop sending. The serial
> >
> > This is a bug in cdc-acm really. It should not double buffer, but to be
> > fair to the authors prior to the new tty buffering it *had* to do this.
>
> I assume this applies to all serial drivers in the wider sense?
When possible at least. Obviously there will always be some buffering in
the
> In the serial driver this usually just results in dropping
> RTS to signal the remote end to stop sending. The serial
> driver always immediately gives receive data to the tty buffering
> without regard to the throttled state.
>
> I would argue that cdc-acm should do the same as the serial drive
> -obj-$(CONFIG_VIDEO_DEV) +=3D videodev.o
> +obj-$(CONFIG_VIDEO_DEV) +=3D videodev.o tuner.o
That looks wrong. Tuner is only needed for some cards. Put the proper rules
in
---
This sf.net email is sponsored by:ThinkGeek
Stuff, things, and muc
> > Possible, but not required for the initial INQUIRY
>
> The Linux SCSI layer performs a single INQUIRY for the device discovery
> process. It was proposed to shorten this INQUIRY to 36 bytes.
Which is fine. We do a 36 byte inquiry just like windows. If the device
turns out to be scsi-4 we can
> A SCSI device that is broken for INQUIRY is definitely broken for SCSI.
> FYI, we need at least 56 bytes of INQUIRY data to be possible for SPC2
> (SCSI 4).
Possible, but not required for the initial INQUIRY
___
[EMAIL PROTECTED]
To unsubscribe, use
> If understand Martin's proposal right, the SCSI layer should first issue
> a standard 36 byte INQUIRY, even if an application or high level SCSI
> driver wants to get more data; and if byte 4 of the returned data
> indicates that the device can provide more data, a second INQUIRY is
> issued.
P
> > SCSI layer proper. The only problem I can see is a broken device
> > that violates the specs by truncating the additonal length
> > parameter to the buffer length provided. Other than that,
>
> I have the documentation from a scanner vendor which indicates exactly
> this broken behaviour.
So
> Umm.. I'm talking about the SCSI probing function... it requests 255 bytes
> of then throws it away after processing the first 36. The remainder never
> gets sent to anywhere (if I'm reading the code right). It would be up to
> the scanner driver to request an INQUIRY data again...
Which it w
> The Linux-SCSI people (now on the CC:) have rejected the idea of making all
> INQUIRYs 36-bytes. Apparently, there are some HBA drivers which want to
> snoop the INQUIRY data in the vendor-specific area for some reason.
For one the full INQ data is needed by some scanner drivers
> I'm thinkin
> I try to do a readl() just before the writel, the readl freeze the
> computer too. It seems that it's the access to this I/O port that freeze
> the machine. I don't have any knowledge on these chip to understand what
> happens
I wonder if the USB controller started in some kind of powered down
> I put printk instructions in the module, the usb-ohci freeze during
> writel instructions line 2027:
>
> writel(0x628,&ohci->regs->fminterval);
Change it to
{
unsigned long flags2;
save_flags(flags2);
__cli();
pr
14 matches
Mail list logo
