LinuxLists.cc - 2.6.13-mm1

2005-09-01 15:44:55

by Eric Dumazet

[permalink] [raw]

Subject: [PATCH] : struct dentry : place d_hash close to d_parent and d_name to speedup lookups

Attachments:

dentry.patch (0.00 B)

2005-09-01 15:48:33

On Thursday 01 September 2005 18:09, John Stoffel wrote:
> >>>>> "Dominik" == Dominik Karall <[email protected]> writes:
>
> Dominik> When I switch on my external harddisk, which is connected
> Dominik> through usb, the kernel hangs. First time I did that at
> Dominik> bootup there were a lot of backtraces printed on the screen
> Dominik> but they did not find the way in the logfile :/ Now I
> Dominik> switched the drive on while running and everything freezes
> Dominik> after those messages:
>
> Dominik> usb 1-2.2: new high speed USB device using ehci_hcd and address 3
> Dominik> scsi2 : SCSI emulation for USB Mass Storage devices
> Dominik> usb-storage: device found at 3
> Dominik> usb-storage: waiting for device to settle before scanning
> Dominik> Vendor: ST325082 Model: 3A Rev: 3.02
> Dominik> Type: Direct-Access ANSI SCSI revision:
> 00 Dominik> SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
> Dominik> sda: assuming drive cache: write through
> Dominik> SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
> Dominik> sda: assuming drive cache: write through
>
> Have you updated the firmware on the USB enclosure? I have one using
> the Prolific chipset for both USB/Firewire and it was crappy until I
> upgraded the firmware on there. It made all the difference.
>
> Also, can you use this USB enclosure on Windows or another computer?
> And which kernel version are you running? It's not clear if your on
> 2.6.13-mm1 or some other version.

2.6.13-mm1, as mentioned in subject.
The external hdd worked with 2.6.13-rc6-mm1 and 2.6.13-ck1, which were the
last versions I ran. Didn't test 2.6.13-rc6-mm2.

> More details would be good too, such as:
>
> lsusb

Bus 001 Device 004: ID 0840:009c Argosy Research, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0840 Argosy Research, Inc.
idProduct 0x009c
bcdDevice 0.01
iManufacturer 1 Generic
iProduct 2 USB 2.0 Mass Storage Device
iSerial 3 009C0000000049BD
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1

dominik

Attachments:

(No filename) (3.92 kB)
(No filename) (316.00 B)
Download all attachments

2005-09-01 17:34:55

by John Stoffel

[permalink] [raw]

Subject: Re: 2.6.13-mm1

Dominik,

So what is the chipset inside the enclosure? Looking at your output,
the 'Argosy' stuff doesn't tell me anything. You might have to open
up the case to look in there to find more details.

Again, check with your vendor and see if there is newer firmware. And
have you powered up the device without having it plugged into the
system, then plug it in? What happens then?

John

2005-09-01 17:41:19

--- linux-2.6.13-orig/drivers/video/sis/Makefile 2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.13-sisfb/drivers/video/sis/Makefile 2005-09-02 01:22:29.247255624 +0200
@@ -4,4 +4,4 @@

obj-$(CONFIG_FB_SIS) += sisfb.o

-sisfb-objs := sis_main.o sis_accel.o init.o init301.o
+sisfb-objs := sis_main.o sis_accel.o init.o init301.o initextlfb.o

Attachments:

sisfb_mf_patch.diff (347.00 B)

2005-09-01 23:25:30

by Adrian Bunk

[permalink] [raw]

Subject: 2.6.13-mm1: misc mwave issues

On Thu, Sep 01, 2005 at 03:55:42AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.13-rc6-mm2:
>...
> git-serial.patch
>...
> Subsystem trees
>...

This patch contains Alan's patch for fixing the compilation of
drivers/char/mwave/mwavedd.c, but the driver is still marked as BROKEN
which should now be undone.

The MWAVE also got a comment
# PLEASE DO NOT DO THIS - move this driver to drivers/serial

Since it seems this code is mostly unmaintained, can the
mv drivers/char/mwave drivers/serial/
be done in the git-serial tree?

Additionally, drivers/char/mwave/mwavedd.c now requires an
#include "8250.h"
for the serial8250_{,un}register_port prototypes.

TIA
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2005-09-02 01:05:57

> I'm not sure whether these are going in through some other channel,
> but I notice neither the Alan's hvcs.c or icom.c patches are in
> 2.6.13-mm3. In addition, hvc_console.c needs yet another...

Yeah, there is still a whole lot broken in -mm. Your patch below is a
good start though.

Acked-by: Joel Schopp <[email protected]>

> Signed-off-by: Serge Hallyn <[email protected]>
>
> Index: linux-2.6.12/drivers/char/hvc_console.c
> ===================================================================
> --- linux-2.6.12.orig/drivers/char/hvc_console.c 2005-09-12 15:08:41.000000000 -0500
> +++ linux-2.6.12/drivers/char/hvc_console.c 2005-09-12 15:52:08.000000000 -0500
> @@ -597,7 +597,7 @@ static int hvc_poll(struct hvc_struct *h
>
> /* Read data if any */
> for (;;) {
> - count = tty_buffer_request_room(tty, N_INBUF);
> + int count = tty_buffer_request_room(tty, N_INBUF);
>
> /* If flip is full, just reschedule a later read */
> if (count == 0) {
> @@ -633,7 +633,7 @@ static int hvc_poll(struct hvc_struct *h
> tty_insert_flip_char(tty, buf[i], 0);
> }
>
> - if (tty->flip.count)
> + if (tty_buffer_request_room(tty, 1))
> tty_schedule_flip(tty);
>
> /*
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

2005-09-12 17:04:29

by Serge E. Hallyn

[permalink] [raw]

Subject: Re: 2.6.13-mm1

Hmm, this patch itself seems to have a few typos, but so does
the 2.6.13-mm{1,2,3}.

Quoting Alan Cox ([email protected]):
> --- drivers/serial/icom.c~ 2005-09-01 22:37:16.986829264 +0100
> +++ drivers/serial/icom.c 2005-09-01 22:37:16.986829264 +0100
> @@ -737,6 +737,7 @@
>
> status = cpu_to_le16(icom_port->statStg->rcv[rcv_buff].flags);
> while (status & SA_FL_RCV_DONE) {
> + int first = -1;
>
> trace(icom_port, "FID_STATUS", status);
> count = cpu_to_le16(icom_port->statStg->rcv[rcv_buff].leLength);
> @@ -751,15 +752,17 @@
> icom_port->recv_buf_pci;
>
> /* Block copy all but the last byte as this may have status */
> - if(count > 0)
> + if(count > 0) {
> + first = icon->recv_buf[offset];
s/icon/icom_port/ ?

> tty_insert_flip_string(tty, icon_port->recv_buf + offset, count - 1);

s/icon_port/icom_port/ ?

> + }
>
> icount = &icom_port->uart_port.icount;
> icount->rx += count;
>
> /* Break detect logic */
> if ((status & SA_FLAGS_FRAME_ERROR)
> - && (tty->flip.char_buf_ptr[0] == 0x00)) {
> + && first == 0) {
> status &= ~SA_FLAGS_FRAME_ERROR;
> status |= SA_FLAGS_BREAK_DET;
> trace(icom_port, "BREAK_DET", 0);

And in 2.6.13-mm3, we have:

@@ -798,33 +792,26 @@ static void recv_interrupt(u16 port_int_
status &= icom_port->read_status_mask;

if (status & SA_FLAGS_BREAK_DET) {
- *tty->flip.flag_buf_ptr = TTY_BREAK;
+ flag = TTY_BREAK;
} else if (status & SA_FLAGS_PARITY_ERROR) {
trace(icom_port, "PARITY_ERROR", 0);
- *tty->flip.flag_buf_ptr = TTY_PARITY;
+ flag = TTY_PARITY;
} else if (status & SA_FLAGS_FRAME_ERROR)
- *tty->flip.flag_buf_ptr = TTY_FRAME;
+ flag = TTY_FRAME;

- if (status & SA_FLAGS_OVERRUN) {
- /*
- * Overrun is special, since it's
- * reported immediately, and doesn't
- * affect the current character
- */
- if (tty->flip.count < TTY_FLIPBUF_SIZE) {
- tty->flip.count++;
- tty->flip.flag_buf_ptr++;
- tty->flip.char_buf_ptr++;
- *tty->flip.flag_buf_ptr = TTY_OVERRUN;
- }
- }
}

- tty->flip.flag_buf_ptr++;
- tty->flip.char_buf_ptr++;
- tty->flip.count++;
- ignore_char:
- icom_port->statStg->rcv[rcv_buff].flags = 0;
+ tty_insert_flip_char(tty, icon_port->recv_buf + offset + count - 1, flag);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Is this meant to be
tty_insert_flip_char(tty, *(icon_port->recv_buf + offset + count - 1), flag);
?

+
+ if (status & SA_FLAGS_OVERRUN)
+ /*
+ * Overrun is special, since it's
+ * reported immediately, and doesn't
+ * affect the current character
+ */
+ tty_insert_flip_char(tty, 0, TTY_OVERRUN);
+ignore_char:
+ icom_port->statStg->rcv[rcv_buff].flags = 0;
icom_port->statStg->rcv[rcv_buff].leLength = 0;
icom_port->statStg->rcv[rcv_buff].WorkingLength =
(unsigned short int) cpu_to_le16(RCV_BUFF_SZ);

Again, sorry I didn't catch this back in -mm1 or -mm2...

thanks,
-serge