Re: Oops in megaraid_mbox_dpc(), kernel 2.6.23.9-85.fc8.i686
On 02/06/2008 02:38 PM, Yang, Bo wrote:
Andrew/Scott,
Can you give me more details about this issue? Such as: MegaRAID
Controller name, FW version, RAID configuration, host system info, how
to reproduce this issue. Also do you see the issue on other kernel
versions.
He has hit the BUG() here in megaraid_mbox_dpc():
// Make sure f/w has completed a valid command
if (scb-state != SCB_ISSUED) {
con_log(CL_ANN, (KERN_CRIT
megaraid critical err: invalid command %d:%d:%p\n,
scb-sno, scb-state, scp));
BUG();
continue; // Must never happen!
}
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: INITIO scsi driver fails to work properly
On 01/11/2008 10:44 AM, James Bottomley wrote: This proves the BAR0 to be non zero, but I also take it from your report that the initio: I/O port range 0x0 is busy. message is also gone? I havent reported initio: I/O port range 0x0 is busy. Sorry ... we appear to have several reporters of different bugs in this thread. That message was copied by Chuck Ebbert from a Red Hat bugzilla ... I was assuming it was the same problem. Our reporter has applied patches since then and now reports the exact same symptoms that Filippos does. (It just hangs after loading the driver.) - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: INITIO scsi driver fails to work properly
On 12/19/2007 03:48 AM, Filippos Papadopoulos wrote: On Dec 17, 2007 2:18 PM, Boaz Harrosh [EMAIL PROTECTED] wrote: I have found one problem. Please try patch [2] below and report. If it still fails try to enable debugging by setting with patch [1] these values at top of drivers/scsi/initio.c. And send dmsgs. Boaz I tried patch[2] (addition of sg++) at 2.6.24-rc5-mm1 but the system hangs after some seconds when the initio driver loads. I will try patch[1] next week to see what happens. Would it be better to open a bug report at bugzilla? There is also a Fedora bug report against 2.6.23. The user has applied commit e9e42faf47255274a1ed0b9bf1c46118023ec5fa from 2.6.24-rc plus the two additional fixes under discussion and it hangs for him too. https://bugzilla.redhat.com/show_bug.cgi?id=390531 - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: INITIO scsi driver fails to work properly
On 12/21/2007 04:03 PM, James Bottomley wrote: On Fri, 2007-12-21 at 14:30 -0500, Chuck Ebbert wrote: On 12/19/2007 03:48 AM, Filippos Papadopoulos wrote: On Dec 17, 2007 2:18 PM, Boaz Harrosh [EMAIL PROTECTED] wrote: I have found one problem. Please try patch [2] below and report. If it still fails try to enable debugging by setting with patch [1] these values at top of drivers/scsi/initio.c. And send dmsgs. Boaz I tried patch[2] (addition of sg++) at 2.6.24-rc5-mm1 but the system hangs after some seconds when the initio driver loads. I will try patch[1] next week to see what happens. Would it be better to open a bug report at bugzilla? There is also a Fedora bug report against 2.6.23. The user has applied commit e9e42faf47255274a1ed0b9bf1c46118023ec5fa from 2.6.24-rc plus the two additional fixes under discussion and it hangs for him too. https://bugzilla.redhat.com/show_bug.cgi?id=390531 It really sounds like there's some problem applying the patches. The consistent report throughout is this one: initio: I/O port range 0x0 is busy. Which should be fixed by 99f1f534922a2f2251ba05b14657a1c62882a80e. I didn't actually find that in the bug thread anywhere, but maybe I missed it? The I/O port 0 bug just prints the message and the system continues to run. It's only after that is fixed that the system just hangs on boot shortly after loading the driver. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Megaraid driver not detecting RAID volumes in kernel 2.6.22?
https://bugzilla.redhat.com/show_bug.cgi?id=288421 When running Fedora on a Dell 2950 w/ integrated LSI Perc5i (megaraid), the system will not boot after upgrading to 2.6.22. The boot message indicates the system is somehow seeing through RAID, cannot access logical volume. This causes the root device to be unavailable and the kernel to panic. Version-Release number of selected component (if applicable): I experience this problem with kernel 2.6.22 and higher. I do not believe it is isolated to FC6, as I downloaded the stock 2.6.22 kernel from kernel.org and was able to reproduce. How reproducible: Every time. Steps to Reproduce: 1. Configure RAID10 (I've also tried RAID5) on a Perc5i in this system. 2. Load Fedora Core. The installer works fine since the kernel version it uses has a working LSI driver. 3. Upgrade to 2.6.22 kernel image (in yum) or download kernel.org sources, compile, and install. 4. Reboot system. It comes up unable to boot. The kernel panics. Actual results: As the system boots, it cannot mount the root device. Also in the output we see all 6 disks separately, when they should be showing up as one logical volume. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with USB disk [solved]
On 08/13/2007 10:50 AM, Niels wrote: On Sunday 12 August 2007 11:54, Niels wrote: On Friday 10 August 2007 14:43, Niels wrote: On Wednesday 08 August 2007 12:57, Ismail Dönmez wrote: On Wednesday 08 August 2007 13:48:29 you wrote: On Tuesday 07 August 2007 23:18, Greg KH wrote: On Tue, Aug 07, 2007 at 10:26:15PM +0200, Niels wrote: Hi, I'm having problems with a new 500 GB USB disk. It works, but sometimes I get these in dmesg: usb 1-3: reset high speed USB device using ehci_hcd and address 2 usb 5-1: USB disconnect, address 2 drivers/usb/class/usblp.c: usblp0: removed sd 0:0:0:0: Device not ready: 6: Sense Key : 0x2 [current] : ASC=0x4 ASCQ=0x2 end_request: I/O error, dev sda, sector 254148215 sd 0:0:0:0: Device not ready: 6: Sense Key : 0x2 [current] : ASC=0x4 ASCQ=0x2 end_request: I/O error, dev sda, sector 252434023 EXT3-fs error (device sda1): ext3_find_entry: reading directory #15761836 offset 0 There's also a printer connected. This is on a pci/usb2 card. When the above happens, I get I/O errors. When I mount the drive next, there are errors and often missing files. Quite annoying! Kernel is 2.6.21 What's going on? You have a low voltage issue, or a bad cable. The device is electronically disconnecting itself. Try using a externally-powered hub, or a new cable. I am seeing a similar problem with 2.6.22 and 2.6.23-* kernels with my 60G iPod Video, works fine with 2.6.18 kernel though. So far I'm seeing this: - On 2.6.21 I mount the drive. After a while it spins down, and when I then unmount it, an error pops up in dmesg. - On 2.6.18 I can't provoke the same error. The drive doesn't appear to spin down. I don't know if the data corruption from 2.6.21 occurs with regular use. There are a number of other factor I need to eliminate on my system, but that's it so far. CONFIG_USB_SUSPEND is not set on either kernel. OK, on a vanilla 2.6.18.8 I also have this problem, with both the pci/usb2 card, and the usb1 on the board. I listen to music from the drive, and after some time (10-20 minutes or so), it freaks out: = sd 1:0:0:0: Device not ready: 6: Current: sense key=0x2 ASC=0x4 ASCQ=0x2 end_request: I/O error, dev sda, sector 126693711 sd 1:0:0:0: Device not ready: 6: Current: sense key=0x2 ASC=0x4 ASCQ=0x2 end_request: I/O error, dev sda, sector 126693711 sd 1:0:0:0: Device not ready: 6: Current: sense key=0x2 ASC=0x4 ASCQ=0x2 end_request: I/O error, dev sda, sector 126693711 = Using a new PSU and a powered hub made no difference. But I found a solution here: http://alienghic.livejournal.com/382903.html Basically, the problem is, as suspected, that the drive spins down / goes to suspend. This can be disabled with sdparm --clear STANDBY -6 /dev/sda. It seems to me to be an error that the kernel reports this as something like a hardware failure. Or at least very misleading. Oh, nice. The usb-storage (SCSI) disk spins itself down and we can't handle that. Should we be disabling auto-spindown when we connect the device, or be able to handle this by sending the start command when needed? - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 2.6.22 released
On 07/09/2007 06:14 AM, Alan Cox wrote:
Are the shortlogs useful - yes .. they catch what appear to be mistakes
Specifically: What happened to the aacraid ioctl security fix ? Did someone
decide it
wasn't needed or did it get lost somewhere on the way ?
While this looks scary the only obvious exploit cases are where the user can
open a device level file on an AACraid. Very few people put scanners or CD
devices on one so the actual impact is probably minimal.
I can't find that patch in any SCSI git tree.
--- drivers/scsi/aacraid/linit.c~ 2007-07-09 10:51:55.653223304 +0100
+++ drivers/scsi/aacraid/linit.c 2007-07-09 10:51:55.653223304 +0100
@@ -453,6 +453,8 @@
static int aac_ioctl(struct scsi_device *sdev, int cmd, void __user * arg)
{
struct aac_dev *dev = (struct aac_dev *)sdev-host-hostdata;
+ if (!capable(CAP_SYS_RAWIO))
+ return -EPERM;
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] final SCSI updates for 2.6.21
James Bottomley wrote: This should be the second half of the SCSI tree, mainly assorted driver updates and fixes. The patch is available from: Is Doug Chapman's patch for mptspi going in? http://marc.info/?l=linux-scsim=117857313402574q=raw [PATCH] fix for BZ 8426 - massive slowdown on SCSI CD/DVD drive - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] unable to handle kernel paging request at virtual address 0800000e
Thomas Meyer wrote:
dmesg output:
pktcdvd: pkt_get_last_written failed
BUG: unable to handle kernel paging request at virtual address 080e
SNIP
EFLAGS: 00010203 (2.6.21-rc6 #295)
SNIP
cdrom: This disc doesn't have any tracks I recognize!
This happens while calling command pktsetup.
Well that's very strange.
long do_sys_open(int dfd, const char __user *filename, int flags, int mode)
{
char *tmp = getname(filename);
int fd = PTR_ERR(tmp);
if (!IS_ERR(tmp)) {
fd = get_unused_fd();
if (fd = 0) {
struct file *f = do_filp_open(dfd, tmp, flags, mode);
if (IS_ERR(f)) {
put_unused_fd(fd);
fd = PTR_ERR(f);
} else {
fsnotify_open(f-f_path.dentry);
fd_install(fd, f);
}
}
putname(tmp);
}
do_filp_open has returned 0x802
Isn't that a SCSI error of some kind?
IAC we have tried to do fsnotify_open(f-f_path.dentry) with that result...
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Oops in scsi_send_eh_cmnd 2.6.21-rc5-git6,7,10
Andrew Burgess wrote: The machine is x86_64 SMP. I also got the oops in the Fedora kernels: 2.6.20-1.2933.fc6 and 2.6.20-1.3017.fc7. The system isn't locked solid but it seems anything touching the scsi disks hangs. I also twice got this early in the boot and it stopped booting. Anything I can do to help just ask. The backtrace claims my kernel is tainted due to a machine check execption but I can find no message in the logs using 'egrep -i 'mce|machine|check|exception'. It only claims the kernels that I compile are tainted, not the Fedora ones. [EMAIL PROTECTED]:log # (zcat messages.2.gz messages.1.gz ; cat messages)|grep -i taint Mar 28 02:38:48 cichlid kernel: Pid: 393, comm: scsi_eh_0 Not tainted 2.6.20-1.2933.fc6 #1 Mar 28 02:38:55 cichlid kernel: Pid: 395, comm: scsi_eh_2 Not tainted 2.6.20-1.2933.fc6 #1 Mar 28 08:56:05 cichlid kernel: Pid: 384, comm: scsi_eh_4 Not tainted 2.6.20-1.3017.fc7 #1 Apr 1 00:30:18 cichlid kernel: Pid: 386, comm: scsi_eh_1 Tainted: G M 2.6.21-rc5-git6-1 #1 Apr 2 15:51:24 cichlid kernel: Pid: 386, comm: scsi_eh_1 Tainted: G M 2.6.21-rc5-git7-1 #1 Apr 2 18:20:13 cichlid kernel: Pid: 388, comm: scsi_eh_1 Tainted: G M 2.6.21-rc5-git7-4 #4 Apr 4 15:27:53 cichlid kernel: Pid: 386, comm: scsi_eh_1 Not tainted 2.6.21-rc5-git9-1 #1 Apr 5 04:00:08 cichlid kernel: Pid: 386, comm: scsi_eh_0 Tainted: G M 2.6.21-rc5-git10-1-slab-debug #1 Apr 5 04:00:08 cichlid kernel: Pid: 390, comm: scsi_eh_2 Tainted: G M 2.6.21-rc5-git10-1-slab-debug #1 Apr 5 08:25:41 cichlid kernel: Pid: 386, comm: scsi_eh_0 Tainted: G M 2.6.21-rc5-git10-1-slab-debug #1 The Oops seems to be the memcpy in scsi_send_eh_cmnd. The BUG appears to be in the oops handler itself. Earlier oopsen happened in kfree so I turned on slab debugging. Apr 5 03:45:16 cichlid kernel: 3w-: scsi2: Command failed: status = 0xc7, flags = 0x7f, unit #4. Apr 5 03:45:20 cichlid kernel: 3w-: scsi2: Command failed: status = 0xc7, flags = 0x80, unit #4. Apr 5 03:47:20 cichlid kernel: 3w-: scsi0: Command failed: status = 0xc7, flags = 0x80, unit #0. Apr 5 03:47:20 cichlid kernel: 3w-: scsi0: Command failed: status = 0xc7, flags = 0x80, unit #1. Apr 5 04:00:08 cichlid kernel: 3w-: scsi0: Command failed: status = 0xc7, flags = 0x80, unit #0. Apr 5 04:00:08 cichlid kernel: BUG: using smp_processor_id() in preemptible [0001] code: scsi_eh_0/386 Apr 5 04:00:08 cichlid kernel: caller is oops_begin+0xc/0x80 Apr 5 04:00:08 cichlid kernel: Apr 5 04:00:08 cichlid kernel: Call Trace: Apr 5 04:00:08 cichlid kernel: [debug_smp_processor_id+181/208] debug_smp_processor_id+0xb5/0xd0 Apr 5 04:00:08 cichlid kernel: [8034de35] debug_smp_processor_id+0xb5/0xd0 Apr 5 04:00:08 cichlid kernel: [oops_begin+12/128] oops_begin+0xc/0x80 Apr 5 04:00:08 cichlid kernel: [80272dbc] oops_begin+0xc/0x80 Apr 5 04:00:08 cichlid kernel: [die+41/112] die+0x29/0x70 Apr 5 04:00:08 cichlid kernel: [80273559] die+0x29/0x70 Apr 5 04:00:08 cichlid kernel: [do_general_protection+284/304] do_general_protection+0x11c/0x130 Apr 5 04:00:08 cichlid kernel: [8027437c] do_general_protection+0x11c/0x130 Apr 5 04:00:08 cichlid kernel: [error_exit+0/150] error_exit+0x0/0x96 Apr 5 04:00:08 cichlid kernel: [8026ef7d] error_exit+0x0/0x96 Apr 5 04:00:08 cichlid kernel: [memcpy_c+11/32] memcpy_c+0xb/0x20 Apr 5 04:00:08 cichlid kernel: [8026a7cb] memcpy_c+0xb/0x20 Apr 5 04:00:08 cichlid kernel: [_end+123674792/2126102956] :scsi_mod:scsi_send_eh_cmnd+0x3fc/0x480 Apr 5 04:00:08 cichlid kernel: [88055efc] :scsi_mod:scsi_send_eh_cmnd+0x3fc/0x480 Apr 5 04:00:08 cichlid kernel: [thread_return+230/301] thread_return+0xe6/0x12d Apr 5 04:00:08 cichlid kernel: [8026b699] thread_return+0xe6/0x12d Apr 5 04:00:08 cichlid kernel: [_end+123678124/2126102956] :scsi_mod:scsi_error_handler+0x0/0x540 Apr 5 04:00:08 cichlid kernel: [88056c00] :scsi_mod:scsi_error_handler+0x0/0x540 Apr 5 04:00:08 cichlid kernel: [keventd_create_kthread+0/144] keventd_create_kthread+0x0/0x90 Apr 5 04:00:08 cichlid kernel: [802a21c0] keventd_create_kthread+0x0/0x90 Apr 5 04:00:08 cichlid kernel: [kthread+218/272] kthread+0xda/0x110 Apr 5 04:00:08 cichlid kernel: [80237b1a] kthread+0xda/0x110 Apr 5 04:00:08 cichlid kernel: [child_rip+10/18] child_rip+0xa/0x12 Apr 5 04:00:08 cichlid kernel: [80268ea8] child_rip+0xa/0x12 Apr 5 04:00:08 cichlid kernel: [schedule_tail+124/240] schedule_tail+0x7c/0xf0 Apr 5 04:00:08 cichlid kernel: [8022b90c] schedule_tail+0x7c/0xf0 Apr 5 04:00:08 cichlid kernel: [restore_args+0/48] restore_args+0x0/0x30 Apr 5 04:00:08 cichlid kernel: [80268590] restore_args+0x0/0x30 Apr 5 04:00:08 cichlid kernel: [kthread+0/272] kthread+0x0/0x110 Apr 5 04:00:08 cichlid
Re: Kernel 2.6.20 does not work anymore with SCSI or SATA on old Opteron / Xeon servers
Stefan Priebe wrote: Hello! With the sysrq i've found the function with is the problem: inode.c = nfs_getattr = nfs_sync_mapping_range I've also found the attached patch - which is not included in any stable release nor in 2.6.21.X but is public since 20.02.07 I think this is very important. It is queued for 2.6.20.4. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
SCSI devices with 256-byte sectors don't work?
Apparently there really are such devices: Sep 28 20:05:42 localhost kernel: scsi4 : SCSI emulation for USB Mass Storage devices Sep 28 20:05:42 localhost kernel: Vendor: Sandisk Model: ImageMate SDDR09 Rev: 0100 Sep 28 20:05:42 localhost kernel: Type: Direct-AccessANSI SCSI revision: 02 Sep 28 20:05:51 localhost kernel: sddr09: Found Flash card, ID = 98 EA 00 00: Manuf. Toshiba, 2 MB Sep 28 20:05:51 localhost kernel: SCSI device sdd: 8160 256-byte hdwr sectors (2 MB) Sep 28 20:05:51 localhost kernel: sdd: test WP failed, assume Write Enabled Sep 28 20:05:51 localhost kernel: sdd: assuming drive cache: write through Sep 28 20:05:51 localhost kernel: sdd:SCSI error : 4 0 0 0 return code = 0x1007 Sep 28 20:05:51 localhost kernel: end_request: I/O error, dev sdd, sector 0 Sep 28 20:05:51 localhost kernel: Buffer I/O error on device sdd, logical block 0 Last three lines just repeat over and over. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] Re: SCSI logging sucks
Randy Dunlap wrote: Patch for Documentation/kernel-parameters.txt is below. Want more/different? Is this part of drivers/scsi/Kconfig correct?? config SCSI_LOGGING bool SCSI logging facility depends on SCSI ---help--- This turns on a logging facility that can be used to debug a number of SCSI related problems. If you say Y here, no logging output will appear by default, but you can enable logging by saying Y to /proc file system support and Sysctl support below and executing the command echo scsi log token [level] /proc/scsi/scsi at boot time after the /proc file system has been mounted. There are a number of things that can be used for 'token' (you can find them in the source: file:drivers/scsi/scsi.c), and this allows you to select the types of information you want, and the level allows you to select the level of verbosity. I have no clue whether that works, but looking at scsi.c it would seem it doesn't. I only see add-single-device and remove-single-device in there. From: Randy Dunlap [EMAIL PROTECTED] Minor corrections and additions to 'scsi_logging_level', as pointed out by Chuck Ebbert. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- Documentation/kernel-parameters.txt |5 - 1 file changed, 4 insertions(+), 1 deletion(-) --- linux-2620-work.orig/Documentation/kernel-parameters.txt +++ linux-2620-work/Documentation/kernel-parameters.txt @@ -1444,7 +1444,10 @@ and is between 256 and 4096 characters. Format: vendor:model:flags (flags are integer value) - scsi_logging= [SCSI] + scsi_logging_level= [SCSI] a bit mask of logging levels + See drivers/scsi/scsi_logging.h for bits. Also + settable via sysctl at dev.scsi.logging_level + (/proc/sys/dev/scsi/logging_level). scsi_mod.scan= [SCSI] sync (default) scans SCSI busses as they are discovered. async scans them in kernel threads, Patch looks good. The script from IBM looks even better. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
SCSI logging sucks
SCSI logging isn't documented very well, and what little there is
has a problem:
In Documentation/kernel-parameters.txt we have:
scsi_logging= [SCSI]
but it's really scsi_logging_level, as seen here in drivers/scsi/scsi.c:
module_param(scsi_logging_level, int, S_IRUGO|S_IWUSR);
MODULE_PARM_DESC(scsi_logging_level, a bit mask of logging levels);
Not exactly helpful. And the sysctl is called:
/proc/sys/dev/scsi/logging_level
Using scsi_logging.h, I came up with this:
0x7 111 Error
0x38 11 1 Timeout
0x1c0 1 11 Scan
0xe00 111 Midlevel queue
0x7000 111 Midlevel
completions
0x38000 11 1Lowlevel queue
0x1c 1 11Lowlevel
completions
0xe0111Highlevel queue
0x700111Highlevel
completions
0x380011 1 IOCTL
but I'm not sure if it's right.
And the actual implementation looks backwards, at least for highlevel
events. You need to set the level to 80 to see driver loads and
that means wading through tons of extraneous crap. The logging
should show more verbosity at the higher numbers, not start
out with the most verbose output at the low numbers.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
