headers
Alan Stern | 1 Nov 2008 17:54
Picon
Favicon

Problems with the block-layer timeouts

James and Jens:

I spent most of the day yesterday debugging some tricky problems in the
new block-layer timeout scheme.  Clearly it is in need of more work.

A major reason for these problems was that there doesn't seem to be a 
clear a idea of when the timeout period should begin.  In 
blk_add_timer() a comment says:

 *    Each request has its own timer, and as it is added to the queue, we
 *    set up the timer.

On the other hand, elv_next_request() says:

			 * We are now handing the request to the hardware,
			 * add the timeout handler

(Note that this comment is wrong for an additional reason.  
elv_next_request() doesn't hand the request to the hardware; it hands 
the request to a driver.  What the driver chooses to do with the 
request is its own affair.)

So when should the timeout begin?  The most logical time is when the 
driver does send the request to the hardware.  Of course, the block 
core has no way to know when that happens, so a suitable proxy might be 
when the request is removed from the block queue.  (On the other hand, 
are there drivers which don't bother to dequeue a request until it has 
completed?)  Either way, both the comments above and the actual code 
should be changed.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Subba Mungara | 1 Nov 2008 18:23
Picon

Libsas question

Hi,

  I am trying to write a linux driver for a SAS HBA. Can someone
explain where does libsas fit into the linux scsi subsystem (aka three
layer architecture upper, mid, lower layers)?

Thanks,
-Subba
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Adel Gadllah | 1 Nov 2008 18:56
Picon

Re: [PATCH v5] cmdfilter: clean up sysfs interface

The sysfs bits got disabled in 2.6.27 in commit
2dc75d3c3b49c64fd26b4832a7efb75546cb3fc5 .
What are the remaining bugs that needs to get fixed to reenable it for
2.6.28 (or if its too late .29) ?
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Rafael J. Wysocki | 2 Nov 2008 17:04
Picon
Gravatar

2.6.28-rc2-git7: Reported regressions from 2.6.27

This message contains a list of some regressions from 2.6.27, for which there
are no fixes in the mainline I know of.  If any of them have been fixed already,
please let me know.

If you know of any other unresolved regressions from 2.6.27, please let me know
either and I'll add them to the list.  Also, please let me know if any of the
entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.

Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2008-11-02       55       41          29
  2008-10-25       26       25          20

Unresolved regressions
----------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11937
Subject		: ext3 __log_wait_for_space: no transactions
Submitter	: Meelis Roos <mroos@...>
Date		: 2008-10-30 9:49 (4 days old)
References	: http://marc.info/?l=linux-kernel&m=122536026105643&w=4
Handled-By	: Theodore Tso <tytso@...>

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11928
(Continue reading)

Permalink | Reply | 39 comments |
headers
Mike Anderson | 2 Nov 2008 21:35
Picon

Re: Problems with the block-layer timeouts

Alan Stern <stern <at> rowland.harvard.edu> wrote:
> I spent most of the day yesterday debugging some tricky problems in the
> new block-layer timeout scheme.  Clearly it is in need of more work.
> 
> A major reason for these problems was that there doesn't seem to be a 
> clear a idea of when the timeout period should begin.  In 
> blk_add_timer() a comment says:

> How should this be fixed?  It would help to call scsi_dev_queue_ready()  
> before elv_next_request(), but that's not sufficient.  
> scsi_times_out() needs to recognize that a timeout for a non-running
> request can be handled by directly returning BLK_EH_HANDLED.  Right?
> 
> 

Tejun described a similar issue here.
http://thread.gmane.org/gmane.linux.ide/35603

And a fix to address the issue here.
http://thread.gmane.org/gmane.linux.ide/35725

Does the patch posted by Tejun address your issue?

> While I'm on the subject, there are a few related items that could be 
> improved.  In my tests, I was generating I/O requests simply by doing
> 
> 	dd if=/dev/sda ...
> 
> I don't know where the timeouts for these requests are determined, but
> they were set to 60 seconds.  That seems much too long.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthias Andree | 3 Nov 2008 02:36
Picon
Picon

WARNING in 2.6.27.4 pci-dma::dma_free_coherent, during unload of sym53c8xx_2

Hi,

I killall -9'ed "taper" because my SCSI hardware was going haywire,
and tried to rmmod sym53c8xx, and got a nice warning from the kernel -
shown below.

[Please Cc: replies, I'm subscribed to linux-kernel <at> , but not linux-scsi <at> ]

The machine had been suspended to disk before (via /sys/power/state).

------------[ cut here ]------------
WARNING: at arch/x86/kernel/pci-dma.c:376 dma_free_coherent+0x80/0x90()
Modules linked in: nls_utf8 nls_cp437 vfat fat lp tun iptable_mangle ipt_MASQUERADE iptable_nat nf_nat
ipt_REJECT ipt_recent nf_conntrack_ipv4 xt_state xt_TCPMSS xt_tcpudp pppoe pppox af_packet
ppp_generic slhc iptable_filter ip_tables ip6table_filter ip6_tables x_tables snd_pcm_oss
snd_mixer_oss snd_seq ipv6 nf_conntrack_sip nf_conntrack_irc nf_conntrack_ftp nf_conntrack it87
hwmon_vid hwmon fuse dm_crypt ufs xfs loop dm_mod bnep rfcomm l2cap tuner tea5767 tda8290 tuner_xc2028
xc5000 tda9887 tuner_simple tuner_types mt20xx tea5761 snd_via82xx snd_via82xx_modem tvaudio
snd_ac97_codec msp3400 snd_mpu401_uart ppdev ns558 rtc_cmos st bttv ohci1394 rtc_core floppy
gameport snd_rawmidi rtc_lib ac97_bus snd_seq_device ieee1394 serio_raw snd_pcm videodev btusb
snd_timer via_rhine snd_page_alloc v
 4l1_compat snd usb_storage soundcore bluetooth i2c_viapro ir_common compat_ioctl32 i2c_algo_bit
v4l2_common videobuf_dma_sg usblp videobuf_core btcx_risc sr_mod tveeprom cdrom sg 3c59x i2c_core
mii parport_pc parport button joydev usbhid uhci_hcd ehci_hcd usbcore sd_mod crc_t10dif via82cxxx
ide_core pata_amd sata_nv edd ext3 mbcache jbd fan sym53c8xx(-) sata_via pata_via thermal processor
Pid: 27228, comm: rmmod Not tainted 2.6.27.4-default #14
 [<c037681a>] ? printk+0x18/0x1e
 [<c0129874>] warn_on_slowpath+0x54/0x80
 [<c0122bad>] ? check_preempt_wakeup+0x16d/0x1a0
 [<c0123cb6>] ? try_to_wake_up+0xd6/0x1a0
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Wilcox | 3 Nov 2008 04:33

Re: WARNING in 2.6.27.4 pci-dma::dma_free_coherent, during unload of sym53c8xx_2

On Mon, Nov 03, 2008 at 02:36:47AM +0100, Matthias Andree wrote:
> Hi,
> 
> I killall -9'ed "taper" because my SCSI hardware was going haywire,
> and tried to rmmod sym53c8xx, and got a nice warning from the kernel -
> shown below.
> 
> [Please Cc: replies, I'm subscribed to linux-kernel <at> , but not linux-scsi <at> ]
> 
> The machine had been suspended to disk before (via /sys/power/state).
> 
> ------------[ cut here ]------------
> WARNING: at arch/x86/kernel/pci-dma.c:376 dma_free_coherent+0x80/0x90()

Nothing to worry about.  It's a warning on x86 because it's a bug on
ARM.

--

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
FUJITA Tomonori | 3 Nov 2008 05:01
Picon
Gravatar

Re: [PATCH v5] cmdfilter: clean up sysfs interface

On Sat, 1 Nov 2008 18:56:20 +0100
"Adel Gadllah" <adel.gadllah <at> gmail.com> wrote:

> The sysfs bits got disabled in 2.6.27 in commit
> 2dc75d3c3b49c64fd26b4832a7efb75546cb3fc5 .
> What are the remaining bugs that needs to get fixed to reenable it for
> 2.6.28 (or if its too late .29) ?

cmdfilter has some design problems related with the way to use kobject
(discussed several times on lkml during 2.6.27-rcX cycles). As far as
I know, nobody tries to fix them.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
bugme-daemon | 3 Nov 2008 08:58

[Bug 11943] New: Boot fails at scsi0:MESH with hde: lost interrupt, AEC6260

http://bugzilla.kernel.org/show_bug.cgi?id=11943

           Summary: Boot fails at scsi0:MESH with hde: lost interrupt,
                    AEC6260
           Product: IO/Storage
           Version: 2.5
     KernelVersion: 2.6.25.2.3
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: SCSI
        AssignedTo: linux-scsi <at> vger.kernel.org
        ReportedBy: eshaffer1 <at> mac.com

Latest working kernel version: none
Earliest failing kernel version: 2.6.24-19
Distribution: Ubuntu
Hardware Environment: PowerMac B&W G3(rev.1) upgraded to G4 600 mHz cpu,
AEC6260 (ide-pci card)
Software Environment: Ubuntu Intrepid
Problem Description: Install successful from Live CD (Hardy) and Alternate CD
(Hardy / Intrepid). Boot proceeds normally until:
scsi0:MESH 
hde: max request size: 128KiB
boot hangs with repeated lost interrupt, DMA recovery messages. Boot cannot
proceed beyond this point.
(Continue reading)

Permalink | Reply | 2 comments |
headers
bugme-daemon | 3 Nov 2008 09:02

[Bug 11898] mke2fs hang on AIC79 device.

http://bugzilla.kernel.org/show_bug.cgi?id=11898

------- Comment #5 from alex.shi <at> intel.com  2008-11-03 00:02 -------
still exists in rc3 

--

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane