Re: After uprade to buster: QEMU doesn't support -drive if=scsi

[didier gaumet]

Hello,

I have never used SCSI hardware nor SCSI emulation but there is an
Oracle doc here that seems to separate options between -device and -
drive lines:
https://blogs.oracle.com/linux/post/how-to-emulate-block-devices-with-qemu

After uprade to buster: QEMU doesn't support -drive if=scsi

[Urs Thuermann]

After uprading from stretch to buster on my server (x86_64), I cannot
start one of my VMs anymore.  The guest is a *very* old Linux (non
Debian, i686, kernel 2.4, GRUB 1.99) and uses the Symbios Logic
sym53c8xx_2 SCSI driver in its init-ramdisk to mount the root file
system and another virtual disk containing LVM.  The init-ramdisk also
has an IDE driver.

The newer QEMU seems not to support this virtual SCSI adaptor:

# kvm -cpu pentium3 ... \
  -drive 
file=/dev/vg0/.sda,format=raw,if=scsi,media=disk,cache=writeback" \
  -drive 
file=/dev/vg0/.sdb,format=raw,if=scsi,media=disk,cache=writeback" \
qemu-system-x86_64: -drive 
file=/dev/vg0/.sda,format=raw,if=scsi,media=disk,cache=writeback: 
machine type does not support if=scsi,bus=0,unit=0
qemu-system-x86_64: -drive 
file=/dev/vg0/.sdb,format=raw,if=scsi,media=disk,cache=writeback: 
machine type does not support if=scsi,bus=0,unit=1

To be able to start the VM, I have changed the options -drive ... to
-hda and -hdb to use the IDE drivers in the guest.  This works
(somewhat) but performance is *extremely* poor.  Several 10 times
slower than with SCSI.

Another problem, which I don't know whether it's related to the disk
I/O performance, is that ntpd is not even able to sync the system
clock.  Even when there is almost no disk I/O.

Is there any chance of getting this guest running with the old SCSI
adaptor in this new version of QEMU in buster?

I could also try to compile a new Linux 2.4 kernel and build a new
init-ramdisk.  But which driver should I use? In Linux 2.4 there is no
virtio.

In the long run I should clearly move the whole thing to a newer
Debian Linux machine.  But as I am short of time currently, I'd like
to be able to continue with this old VM, at least for a while.

Steve

Re: linux 4.19 scsi-mq default?

[Reco]

Hi.

On Sun, Aug 26, 2018 at 07:47:54PM -0400, Boyan Penkov wrote:
> Hello folks,
> 
> Likely not the exact right list to ask, but likely someone here knows — did 
> scsi-mq by default make it into linux 4.19?
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1807.0/02224.htm

4.19-rc1 has SCSI_MQ_DEFAULT defined as "y" - [1].
Whenever they build it in Debian that way remains to be seen.

Reco

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/Kconfig?h=v4.19-rc1

Re: linux 4.19 scsi-mq default?

[Stefan Krusche]

Hi Boyan,

Am Montag, 27. August 2018 schrieb Boyan Penkov:
> Hello folks,
>
> Likely not the exact right list to ask, but likely someone here knows — did
> scsi-mq by default make it into linux 4.19?
>
> http://lkml.iu.edu/hypermail/linux/kernel/1807.0/02224.html
> <http://lkml.iu.edu/hypermail/linux/kernel/1807.0/02224.html>

This post on lkml is talking about a kernel option. These options are usually 
documented in /boot/config-4.x.y (according to installed kernels). I can't tell 
for your kernel as I don't have 4.19 installed but you easily can check for 
yourself by running this command (example for my system):

$ grep SCSI_MQ_DEFAULT /boot/config-4.9.0-8-amd64
# CONFIG_SCSI_MQ_DEFAULT is not set

HTH

Kind regards,
Stefan

linux 4.19 scsi-mq default?

[Boyan Penkov]

Hello folks,

Likely not the exact right list to ask, but likely someone here knows — did 
scsi-mq by default make it into linux 4.19?

http://lkml.iu.edu/hypermail/linux/kernel/1807.0/02224.html 
<http://lkml.iu.edu/hypermail/linux/kernel/1807.0/02224.html>

Cheers!
--
Boyan Penkov
www.boyanpenkov.com

SCSI rescan (Mint 17.3)

[Paul Duncan]

Hi,

I'm updating wiki documentation for one of our systems, which has an LTO 
tape drive hooked up to an HP P411 SAS RAID controller.


In the good old days of the cciss driver we could issue the following 
command to get the drive recognised if the system had been booted 
without it being switched on:


   echo rescan >/proc/scsi/cciss/6

According to things I have read, the following should work with a modern 
system:


   echo 1 >/sys/class/scsi_host/host0/scan

But all I get is an error message if I try that. Does anyone have an 
idea of where I'm going wrong?


Thanks!

Paul.

Re: wodim "Cannot open SCSI driver!"

[Emanuel Berg]

Gene Heskett  writes:

> Point being Lisi, that its without a doubt of
> Chinese manufacture and the price on your store
> shelf should be comparable +- shipping and of course
> any resttrictive tarrifs your government may have in
> place one way or the other. Some call it a customs
> tax, but the effect is the same, raises your price
> tag considerably while doing nothing but stuffing
> some politicians pocket.

Regardless of whatever, it isn't expensive.

Especially not if it doesn't brake for many years and
all the while do useful stuff. If it fails on either
than it sucks anyway no matter how cheap.

Many people spend more money on food which they then
throw away, every month.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: wodim "Cannot open SCSI driver!"

[Gene Heskett]

On Monday 25 January 2016 05:13:23 Lisi Reisz wrote:

> On Monday 25 January 2016 00:45:58 Gene Heskett wrote:
> > I bought the last burner I have, about 3 or 4 years ago at wallmart,
> > everything but Blue Ray, for about a $25 dollar bill. Internal, sata
> > interface.
>
> Don't gloat, Gene. ;-)*
>
> Lisi
> *Tech prices in the USA are very low compared with many of us.

Point being Lisi, that its without a doubt of Chinese manufacture and the 
price on your store shelf should be comparable +- shipping and of course 
any resttrictive tarrifs your government may have in place one way or 
the other. Some call it a customs tax, but the effect is the same, 
raises your price tag considerably while doing nothing but stuffing some 
politicians pocket.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: wodim "Cannot open SCSI driver!"

[Lisi Reisz]

On Monday 25 January 2016 00:45:58 Gene Heskett wrote:
> I bought the last burner I have, about 3 or 4 years ago at wallmart,
> everything but Blue Ray, for about a $25 dollar bill. Internal, sata
> interface.

Don't gloat, Gene. ;-)*

Lisi
*Tech prices in the USA are very low compared with many of us.

Re: wodim "Cannot open SCSI driver!"

[Thomas Schmitt]

Hi,

Emanuel Berg wrote:
> Sense Code: 0x3A Qual 0x00 (medium not present) Fru 0x0

That's another member of the family of medium-not-present messages:
  2 3A 00 MEDIUM NOT PRESENT
  2 3A 01 MEDIUM NOT PRESENT  TRAY CLOSED
  2 3A 02 MEDIUM NOT PRESENT  TRAY OPEN
  2 3A 03 MEDIUM NOT PRESENT  LOADABLE


Gene Heskett wrote:
> I've had a small wagon load of junk optical drives over the last 18 
> years,

I trust you are old enough not to bundle their lasers into a device
for drilling to China.


Have a nice day :)

Thomas

Re: wodim "Cannot open SCSI driver!"

[Gene Heskett]

On Sunday 24 January 2016 18:50:25 Emanuel Berg wrote:

> "Thomas Schmitt"  writes:
> >   wodim -v dev=/dev/sr0 -toc
> >
> > If i run this on an empty drive, i get
> >
> >   ... Current: 0x (Reserved/Unknown) ... Sense
> > Code: 0x3A Qual 0x01 (medium not present - tray
> > closed) Fru 0x0 ... wodim: No disk / Wrong disk!
>
> I get the same, only:
>
> Sense Code: 0x3A Qual 0x00 (medium not present) Fru 0x0
>
> >> I'm used to things in the computer world either
> >> working or not. But perhaps the burner is one thing
> >> where the result can be spotty as well as perfect
> >> or not at all.
> >
> > The process of imprinting information relies in part
> > on chemistry. This opens the door for thermodynamics
> > and its weirdnesses. (How does a Crooke Radiometer
> > work ? What's really behind the Mpemba effect ?
> > Public explanations are ridiculous despite the
> > experimental situation being quite clear.)
> >
> > Nevertheless, if the CD laser diode is dead and the
> > the DVD diode still works, then this is a case of
> > works-not-at-all-with-CD.
>
> Wow! Good answer :)
>
> I went to the tech store today and an extern USB DVD
> burner is 399 SEK ~($46, £33, or €43) - so even the
> common man can get one, I suppose.

I bought the last burner I have, about 3 or 4 years ago at wallmart, 
everything but Blue Ray, for about a $25 dollar bill. Internal, sata 
interface.  It has to date burned 2 or 3 100 count spindles of cd's and 
dvd's, and has never hicupped unless the disk was phony. Some brands 
have a high phony percentage.  From an lshw report:

*-scsi:2
  physical id: 11
  logical name: scsi4
  capabilities: emulated
*-cdrom
 description: DVD-RAM writer
 product: iHAS424   B
 vendor: ATAPI
 physical id: 0.0.0
 bus info: scsi@4:0.0.0
 logical name: /dev/cdrom
 logical name: /dev/cdrw
 logical name: /dev/dvd
 logical name: /dev/dvdrw
 logical name: /dev/sr0
 version: GL1A
 capabilities: removable audio cd-r cd-rw dvd dvd-r dvd-ram
 configuration: ansiversion=5 status=nodisc

I've had a small wagon load of junk optical drives over the last 18 
years, must have at least 10 laying around because I'm a packrat, but 
this one has been a workhorse that doesn't seem to need any oats.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: wodim "Cannot open SCSI driver!"

[Emanuel Berg]

"Thomas Schmitt"  writes:

>   wodim -v dev=/dev/sr0 -toc
>
> If i run this on an empty drive, i get
>
>   ... Current: 0x (Reserved/Unknown) ... Sense
> Code: 0x3A Qual 0x01 (medium not present - tray
> closed) Fru 0x0 ... wodim: No disk / Wrong disk!

I get the same, only:

Sense Code: 0x3A Qual 0x00 (medium not present) Fru 0x0

>> I'm used to things in the computer world either
>> working or not. But perhaps the burner is one thing
>> where the result can be spotty as well as perfect
>> or not at all.
>
> The process of imprinting information relies in part
> on chemistry. This opens the door for thermodynamics
> and its weirdnesses. (How does a Crooke Radiometer
> work ? What's really behind the Mpemba effect ?
> Public explanations are ridiculous despite the
> experimental situation being quite clear.)
>
> Nevertheless, if the CD laser diode is dead and the
> the DVD diode still works, then this is a case of
> works-not-at-all-with-CD.

Wow! Good answer :)

I went to the tech store today and an extern USB DVD
burner is 399 SEK ~($46, £33, or €43) - so even the
common man can get one, I suppose.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: wodim "Cannot open SCSI driver!"

[Thomas Schmitt]

Hi,

> I have suspected a hardware error as well. Is there
> any way to confirm this?

You could try whether it can recognize any kind of other medium:

  wodim -v dev=/dev/sr0 -toc

If i run this on an empty drive, i get

  ...
  Current: 0x (Reserved/Unknown)
  ...
  Sense Code: 0x3A Qual 0x01 (medium not present - tray closed) Fru 0x0
  ...
  wodim: No disk / Wrong disk!

That's what i expect with your drive and problematic media.

With a non-blank CD-RW i get

  ...
  Current: 0x000A (CD-RW)
  ...
  Manufacturer: CMC Magnetics Corporation
  ...
  track:   1 lba: 0 (0) 00:02:00 adr: 1 control: 0 mode: -1
  track:lout lba: 23260 (93040) 05:12:10 adr: 1 control: 0 mode: -1

With a blank CD-R:

  ...
  Current: 0x0009 (CD-R)
  ...
  Sense Code: 0x24 Qual 0x00 (invalid field in cdb) Fru 0x0
  ...
  wodim: Cannot read TOC header
  wodim: Cannot read TOC/PMA

(These complaints are normal. wodim should not try to inspect
the CD-R content after the burner reported that it is blank.)

With blank DVD-R:
  
  ...
  Current: 0x0011 (DVD-R sequential recording)
  ...
  ... same complaints as with blank CD-R ...


> Strange thing tho I recently burned an ISO DVD movie
> to a DVD with no problem.

The laser beams for CD and DVD are of different wavelength.
It seems that there are two different laser diodes used.
  
http://mods-n-hacks.wonderhowto.com/how-to/extract-laser-diodes-from-dvd-burner-computer-drive-398495/


> I'm used to things in the
> computer world either working or not. But perhaps the
> burner is one thing where the result can be spotty as
> well as perfect or not at all.

The process of imprinting information relies in part on chemistry.
This opens the door for thermodynamics and its weirdnesses.
(How does a Crooke Radiometer work ? What's really behind the
Mpemba effect ? Public explanations are ridiculous despite the
experimental situation being quite clear.)

Nevertheless, if the CD laser diode is dead and the the DVD diode
still works, then this is a case of works-not-at-all-with-CD.


Have a nice day :)

Thomas

Re: wodim "Cannot open SCSI driver!"

[Emanuel Berg]

"Thomas Schmitt"  writes:

> Bad news is that you will probably have to get
> a new burner.

I have suspected a hardware error as well. Is there
any way to confirm this?

Strange thing tho I recently burned an ISO DVD movie
to a DVD with no problem. I'm used to things in the
computer world either working or not. But perhaps the
burner is one thing where the result can be spotty as
well as perfect or not at all.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: wodim "Cannot open SCSI driver!"

[Thomas Schmitt]

Hi,

Emanuel Berg wrote:
> http://user.it.uu.se/~embe8573/wodim_log

where i read

> Executing 'test unit ready' command on Bus 1 Target 0, Lun 0 timeout 200s
> CDB:  00 00 00 00 00 00
> Errno: 5 (Input/output error), test unit ready scsi sendcmd: no error
> CDB:  00 00 00 00 00 00
> status: 0x2 (CHECK CONDITION)
> Sense Bytes: 70 00 02 00 00 00 00 0E 00 00 00 00 3A 00 00 00
> Sense Key: 0x2 Not Ready, Segment 0
> Sense Code: 0x3A Qual 0x00 (medium not present) Fru 0x0

The drive replies SCSI error condition 2 3A 00, which means
that it does not see the CD-R.


> Brasero says
> Please replace the disc with a supported CD or DVD.

The GUI programs often inspect the drive and medium situation by
means of the kernel or userspace device management.
Quite a lot of software layers is involved then.

But if the drive says that there is no disc in it, the urge by
Brasero is well understandable but also futile.


> $ wodim -prcap
>  "Does write CD-R media".

It got this info from the drive (which seems willing but inapt).


> wodim -v dev=$DVD -eject -sao $iso

This command should work fine.


> I have tried two CD-Rs brand new from the (same) box -
> same thing.

The good news is that the media are probably still usable
after the failure. (No traces of an attempt to prepare writing
of data to them.)

Bad news is that you will probably have to get a new burner.


Have a nice day :)

Thomas

Re: wodim "Cannot open SCSI driver!"

[Emanuel Berg]

Emanuel Berg  writes:

> The disc is a CD-R

I have tried two CD-Rs brand new from the (same) box -
same thing.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: wodim "Cannot open SCSI driver!"

[Emanuel Berg]

"Thomas Schmitt"  writes:

> wodim -V ...your.wodim.options... 2>&1 | tee -i
> /tmp/wodim_log

http://user.it.uu.se/~embe8573/wodim_log

> What wodim options did you use, exactly ?

zsh: http://user.it.uu.se/~embe8573/conf/.zsh/dvd

burn-iso-to-cd () {
local iso=$1
wodim -v dev=$DVD -eject -sao $iso
}

burn-iso-to-cd-debug () {
local iso=$1
wodim -V dev=$DVD -eject -sao $iso 2>&1 | tee -i /tmp/wodim_log
}

DVD is

/dev/sr0

> If it was for a pure data or audio CD

The disc is a CD-R and the file is an ISO, namely

debian-8.2.0-i386-xfce-CD-1.iso

> then you may try cdrskin instead of wodim. It uses
> libburn, as do Xfburn, Brasero, and xorriso.

Brasero says

Please replace the disc with a supported CD or DVD.

According to

$ wodim -prcap

it "Does write CD-R media".

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: wodim "Cannot open SCSI driver!"

[Thomas Schmitt]

Hi,

Emanuel Berg wrote:
> > $ wodim --devices
> > I get "Cannot open SCSI driver!"

strace reveils that this confusing message comes from the total
lack of /dev/scd* and /dev/hd* device files or links.

I can fix it on my Jessie by

  for i in 0 1 2 3 4 5
  do
test -e /dev/sr"$i" && ln -s /dev/sr"$i" /dev/scd"$i"
  done

  wodim --devices

This yields

  wodim: Overview of accessible drives (5 found) :
  -
   0  dev='/dev/scd0' rwrw-- : 'HL-DT-ST' 'BDDVDRW GGC-H20L'
   1  dev='/dev/scd1' rwrw-- : 'HL-DT-ST' 'DVDRAM GH24NSC0'
   2  dev='/dev/scd2' rwrw-- : 'HL-DT-ST' 'BD-RE  GGW-H20L'
   3  dev='/dev/scd3' rwrw-- : 'Optiarc' 'BD RW BD-5300S'
   4  dev='/dev/scd4' rwrw-- : 'HL-DT-ST' 'BD-RE  BH16NS40'
  -

To Steve McIntyre and Michael Biebl:
Is there a chance to establish some udev rule to create /dev/scd* 
links ?


Have a nice day :)

Thomas

wodim "Cannot open SCSI driver!"

[Thomas Schmitt]

Hi,

Emanuel Berg wrote:
> When I try to burn with wodim, it says
> Errno: 5 (Input/output error), test unit ready
>scsi sendcmd: no error

We will have to dig deeper to untangle this message.


But first i need to send a few complaints to heaven:

> $ wodim --devices
> I get "Cannot open SCSI driver!"

This i can reproduce on Jessie.

  wodim: No such file or directory. 
  Cannot open SCSI driver!
  For possible targets try 'wodim --devices' or 'wodim -scanbus'.

wodim -scanbus does not work either.
(How can it be that unchanged software shows such signs of rot ?)

Funnily, it can operate single drives.
  $ wodim -v dev=/dev/sr4 -inq
  ...
  Linux sg driver version: 3.5.27
  Wodim version: 1.1.11
  ...
  Device seems to be: Generic mmc2 DVD-R/DVD-RW.

(Well, it is a MMC-5 Blu-ray drive.)
 
-

Now for the burn problem.

In order to learn more about the "test unit ready" error, please
repeat the wodim run with additional option -V and catch the
many messages in file /tmp/wodim_log:

  wodim -V ...your.wodim.options... 2>&1 | tee -i /tmp/wodim_log

Send the file /tmp/wodim_log to me in private. I will then post
what i can learn from it.

What wodim options did you use, exactly ?

If it was for a pure data or audio CD, then you may try cdrskin
instead of wodim. It uses libburn, as do Xfburn, Brasero, and xorriso.

  cdrskin ...your.wodim.options...


Have a nice day :)

Thomas

wodim "Cannot open SCSI driver!"

[Emanuel Berg]

When I try to burn with wodim, it says

Errno: 5 (Input/output error), test unit ready
scsi sendcmd: no error

and

$ wodim --devices

I get "Cannot open SCSI driver!"

Ideas?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Cannot access SCSI device

[Christian Schmidt]

Hi all,

at the oment, I'm struggling with a server containing a SCSI card 
(Adaptec ASC-29320ALP) which is connected to an easyRAID. On the 
easyRAID, I've created a big RAID6 array which is divided into two 
slices. Unformntunately, I didn't succeed in accessing those devices:


# gdisk /dev/sdb
GPT fdisk (gdisk) version 0.8.5

Problem opening /dev/sdb for reading! Error is 6.

# ls -l /dev/sdb
brw-rw---T 1 root disk 8, 16 Mar 19 10:36 /dev/sdb

Trying to access /dev/sdc gives the same result.

The server is running Wheezy:
# uname -a
Linux HOSTNAME 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux

"dmesg | grep -i scsi" delivers the followinng output.
(Yes, there is another 3ware SATA RAID controller which works qithout 
any problem)


 cut here 
[1.044596] scsi1 : ahci
[1.044709] scsi2 : ahci
[1.044777] scsi3 : ahci
[1.044844] scsi4 : ahci
[1.044911] scsi5 : ahci
[1.044977] scsi6 : ahci
[1.204030] scsi0 : 3ware 9000 Storage Controller
[1.204125] 3w-9xxx: scsi0: Found a 3ware 9000 Storage Controller at 
0xdfb0, IRQ: 16.
[1.380538] scsi 5:0:0:0: CD-ROMHL-DT-ST DVDRAM GT20N 
CW03 PQ: 0 ANSI: 5
[1.389962] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw 
xa/form2 cdda tray

[1.390148] sr 5:0:0:0: Attached scsi CD-ROM sr0
[1.391757] sr 5:0:0:0: Attached scsi generic sg0 type 5
[1.540088] 3w-9xxx: scsi0: Firmware FE9X 4.08.00.006, BIOS BE9X 
4.08.00.001, Ports: 2.
[1.540513] scsi 0:0:0:0: Direct-Access AMCC 9650SE-2LP DISK 
 4.08 PQ: 0 ANSI: 5

[1.550038] scsi 0:0:0:0: Attached scsi generic sg1 type 0
[   16.100045] scsi7 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 3.0
[   16.153432] scsi: waiting for bus probes to complete ...
[   16.357654] scsi 7:0:1:0: Direct-Access easyRAID  Q16+  R0.0 PQ: 
0 ANSI: 5

[   16.357663] scsi target7:0:1: asynchronous
[   16.357666] scsi7:A:1:0: Tagged Queuing enabled.  Depth 32
[   16.357677] scsi target7:0:1: Beginning Domain Validation
[   16.359235] scsi target7:0:1: wide asynchronous
[   16.360437] scsi target7:0:1: FAST-160 WIDE SCSI 320.0 MB/s DT IU RTI 
WRFLOW PCOMP (6.25 ns, offset 127)

[   16.390568] scsi target7:0:1: Ending Domain Validation
[   16.391085] scsi 7:0:1:1: Direct-Access easyRAID  Q16+  R0.0 PQ: 
0 ANSI: 5

[   16.391091] scsi7:A:1:1: Tagged Queuing enabled.  Depth 32
[   19.730394] sd 7:0:1:0: Attached scsi generic sg2 type 0
[   19.730928] sd 7:0:1:1: Attached scsi generic sg3 type 0
[   49.888591] scsi7: At time of recovery, card was not paused
[   49.888599] scsi7: Dumping Card State at program address 0x9 Mode 0x33
[   49.01] scsi7: FIFO0 Free, LONGJMP == 0x826c, SCB 0x3
[   49.79] scsi7: FIFO1 Free, LONGJMP == 0x8063, SCB 0x3
[   49.888993] scsi7: LQISTATE = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x52
[   49.888998] scsi7: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1
[   49.889002] scsi7: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0
[   49.889023] scsi7: REG0 == 0x, SINDEX = 0x104, DINDEX = 0x104
[   49.889033] scsi7: SCBPTR == 0x3, SCB_NEXT == 0xff80, SCB_NEXT2 == 0xff02
[   49.889119] (scsi7:A:1:1): Device is disconnected, re-queuing SCB
[   49.889149] scsi7: Recovery code sleeping
[   50.659580] scsi7: Device reset code sleeping
[   50.916410] scsi7: Device reset returning 0x2002
[   51.173180] scsi7: Device reset code sleeping
[   51.430033] scsi7: Device reset returning 0x2002
[   95.841119] scsi7: At time of recovery, card was not paused
[   95.841128] scsi7: Dumping Card State at program address 0x20 Mode 0x22
[   95.841360] scsi7: FIFO0 Free, LONGJMP == 0x826c, SCB 0x3
[   95.841446] scsi7: FIFO1 Free, LONGJMP == 0x8063, SCB 0x3
[   95.841570] scsi7: LQISTATE = 0x1, LQOSTATE = 0x1a, OPTIONMODE = 0x52
[   95.841575] scsi7: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x0
[   95.841580] scsi7: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0
[   95.841602] scsi7: REG0 == 0x3, SINDEX = 0x104, DINDEX = 0x104
[   95.841614] scsi7: SCBPTR == 0xff03, SCB_NEXT == 0xff00, SCB_NEXT2 == 0x0
[   95.841691] scsi7:0:1:1: Cmd aborted from QINFIFO
[  105.841603] scsi7: At time of recovery, card was not paused
[  105.841612] scsi7: Dumping Card State at program address 0x0 Mode 0x22
[  105.841833] scsi7: FIFO0 Free, LONGJMP == 0x826c, SCB 0x3
[  105.841920] scsi7: FIFO1 Free, LONGJMP == 0x8063, SCB 0x3
[  105.842043] scsi7: LQISTATE = 0x1, LQOSTATE = 0x1a, OPTIONMODE = 0x52
[  105.842048] scsi7: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x0
[  105.842053] scsi7: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0
[  105.842076] scsi7: REG0 == 0x3, SINDEX = 0x104, DINDEX = 0x104
[  105.842087] scsi7: SCBPTR == 0xff03, SCB_NEXT == 0xff00, SCB_NEXT2 == 0x0
[  105.842148] scsi7:0:1:1: Cmd aborted from QINFIFO
[  105.842190] scsi7: Device reset code sleeping
[  110.840016] scsi7: Device reset timer expired (active 1)
[  110.840020] scsi7: Device reset returning 0x2003
 cut here 


"At time of recovery, card was not paused" seems a little bit odd for 
me, but I

Re: SCSI driver for use with Jessie: which one? [Solved]

[Paul E Condon]

On 20141026_2314-0400, Gary Dale wrote:
> On 26/10/14 09:33 PM, Paul E Condon wrote:
> >I found today that I don't have a scsi driver on my Jessie install.
> >I search for 'scsi' in aptitude and see several competing packages.
> >Which one is most likely to enable burning a new debian netinst CD
> >today or tomorrow? I need to reinstall Jessie on a different host
> >before this one crashes. I'm running xfce4 and xorg. To my knowledge,
> >othing exotic. But always willing to answer questions about obivious
> >essential details that I have left out.
> >
> >TIA
> 
> Drivers are part of the kernel. If you have a SCSI device, the hardware
> detection should find it and load the appropriate driver. If you don't have
> a SCSI device, it may not load the low level driver.
> 
> I gather your problem is that you want to burn a CD using a SCSI writer
> (where did you find one?). If that is the case, what errors are you getting?
> 
> If you're just trying to burn a netinst CD with SCSI packages, don't worry
> about it. Just burn a normal netinst CD. It will download the packages and
> drivers it needs.
> 

I was trying to use wodim, which I have always used since Debian abandoned
cdrecord. Your doubts about my having a SCSI drive knocked me out of my 
mental rut, and I tried using brasero, which was already installed (by the
xfce4-task, I think). It worked and I'm happy.
Thanks.

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141027050232.ga24...@big.lan.gnu

Re: SCSI driver for use with Jessie: which one?

[Gary Dale]

On 26/10/14 09:33 PM, Paul E Condon wrote:

I found today that I don't have a scsi driver on my Jessie install.
I search for 'scsi' in aptitude and see several competing packages.
Which one is most likely to enable burning a new debian netinst CD
today or tomorrow? I need to reinstall Jessie on a different host
before this one crashes. I'm running xfce4 and xorg. To my knowledge,
othing exotic. But always willing to answer questions about obivious
essential details that I have left out.

TIA


Drivers are part of the kernel. If you have a SCSI device, the hardware 
detection should find it and load the appropriate driver. If you don't 
have a SCSI device, it may not load the low level driver.


I gather your problem is that you want to burn a CD using a SCSI writer 
(where did you find one?). If that is the case, what errors are you getting?


If you're just trying to burn a netinst CD with SCSI packages, don't 
worry about it. Just burn a normal netinst CD. It will download the 
packages and drivers it needs.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/544db897.40...@torfree.net

SCSI driver for use with Jessie: which one?

[Paul E Condon]

I found today that I don't have a scsi driver on my Jessie install.
I search for 'scsi' in aptitude and see several competing packages.
Which one is most likely to enable burning a new debian netinst CD
today or tomorrow? I need to reinstall Jessie on a different host
before this one crashes. I'm running xfce4 and xorg. To my knowledge,
othing exotic. But always willing to answer questions about obivious
essential details that I have left out. 

TIA
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141027013344.gc11...@big.lan.gnu

Re: clean hd-media install onto hard drive partition of old SCSI box

[sar0113]

Hi, Chris,

 > You do realise that posts on this mailing list are archived at various
 > places around the Internet, don't you?

Yes, I realize posting to this mailing list exposes the e-mail 
address I have used. The statement, which my editor automatically
adds to all of my emails, indicates my act of posting does not mean 
I approve of address harvesting.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130718131458.ga1...@nc.rr.com

Re: clean hd-media install onto hard drive partition of old SCSI box

[Brian]

On Wed 17 Jul 2013 at 18:12:49 -0400, sar0...@nc.rr.com wrote:

> Thanks for the response (and sorry about replying to your email address
> rather than the list)

Not a problem. I read the list and reply through it and never get to see
mails sent directly to me via that address. Which does not mean it is not
possible to contact me if there is a desparate need to - like giving me
money. :)

> Allegedly the install can hang if the ISO does not 'match" the way
> the kernel/initrd was compiled.  Probably risky, as I have not stumbled
> across a report claiming someone else has done it..

If you are going to install Lenny then the kernel, initrd and ISO *have*
to come from that distribution.

> Thanks again.  Sounds like I am diving down an appropriate rabbit hole!

Your BIOS will not boot from USB but I imagine you have a floppy drive
which can be booted from. It may be worth your while visiting

   http://www.plop.at/en/bootmanagers.html


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130717232516.gl25...@copernicus.demon.co.uk

Re: clean hd-media install onto hard drive partition of old SCSI box

[sar0113]

Thanks for the response (and sorry about replying to your email address
rather than the list)

Good to know Wheezy comes with the Initio driver module. I wasn't
sure how to tell by inspecting Wheezy install CDs. However, I'm going
to install Lenny first as I have the CDs and want to avoid a net
install which was painful in the past on this machine.  I prefer to
take my headaches  one at a time - base install (SCSI driver), X
install (video config) then ethernet access (past problems getting=20
driver settings to 'stick').

I wrote:

 >> I have initialized a 3.3 MB ext3 root partition for Debian 5 and
 >> downloaded the hd-media versions of vmlinuz, initrd.gz, boot.img.gz=20
 >> and a cd ISO from the official Debian archives.=20

Brian replied:

 > The 3.3 MB root partition isn't required. I suppose you could use it,
 > but it appears to me to complicate things.

Opps, *typo* - root partition is 3.3 GB (not MB).  Deducting 0.75 or so
for the ISO and boot kernel files, I'll have about 2.5 GB of space for
the base install and X install. I can move subtrees to another much
larger partition beyond addressable BIOS limits once the base install
is working.

Brian continued:

 > boot.img.gz isn't needed either.

I was scratching my ahead about it, but grabbed it too as one=20
write-up I found used it in a USB flash-drive install.

 > > 1) If I install this kernel and iso image in my Debian 5 root=20
 > > partition with lilo or grub, I should automatically launch the=20
 > > Debian 5 installer after booting this partition, correct?
 >=20
Brian replied:

 > I'd put vmlinuz and initrd.gz in /boot/ and the cd ISO in /, a place
 > where d-i is likely to find it when it looks for it. d-i can also=20
 > locate the ISO if it is on a USB stick.

These are the subdirs I used for my hard drive partition.  However,=20
when I tried to run lilo -r /mnt -t -v, the error message indicated=20
I needed additional file(s) on the file system - see my question=20
#2 below:

Brian continue:

 > You didn't say what your existing bootloader is. GRUB Legacy? If so.=20
 > you write a stanza in its configuration file giving the locations=20
 > of vmlinuz and initrd.gz so you can boot the kernel.

I used lilo for the Woody install, but I installed the (legacy) Grub=20
package for Woody and don't mind using it instead for Debian 5,
but I =1Bsuspect I still need to add additional file(s) to the root file=20
system, ie.:

 > > 2) How do I go about creating the rudimentary file system I need be
 > > able to install lilo or grub on the clean root partition - without
 > > what subdirectories and executables do I  need and where do I find
 > > them without a working Debian 5 system to clone?

* This is where I am still stuck *

 > > 3a) If I can launch the Debian Installer this way, will it allow me to
 > > manually switch package sources from Debian servers to my CD-ROM (which
 > > presumably I can mount once the installer has loaded the Initio SCSI
 > > driver module.)?

Brian replied:

 > This could be done after you have installed from the cd ISO and have
 > booted into the new system.

Good to know.  Hopefully it will be obvious when and how to switch the
package source so I can avoid a hung install.

I wrote:

 > > 3b) If not, will the installer pull packages from my CDs if I replace
 > > the hd-media version of the cd ISO image with the CD version of the
 > > cd #1 ISO image?

Brian replied:

 > You can certainly use cd #1 but, never having done it, I'm not certain
 > about how d-i deals with the other CDs.

Allegedly the install can hang if the ISO does not 'match" the way
the kernel/initrd was compiled.  Probably risky, as I have not stumbled
across a report claiming someone else has done it..

Thanks again.  Sounds like I am diving down an appropriate rabbit hole!


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130717221249.ga1...@nc.rr.com

Re: clean hd-media install onto hard drive partition of old SCSI box

[Brian]

On Wed 17 Jul 2013 at 15:18:27 -0400, sar0...@nc.rr.com wrote:

> I want to install a recent Debian distribution on a clean partition of
> a stand-alone SCSI box which runs multiple legacy OSes, including
> Woody. I did not upgrade Woody because driver support for my Initio
> SCSI host adapter was problematic with supplied 2.6 kernels for
> several years, but apparently resolved according to a Debian bug
> report.

#318121?

On Wheezy:
   brian@desktop:~$ locate initio.ko
   /lib/modules/3.2.0-4-686-pae/kernel/drivers/scsi/initio.ko

So it looks like you are good to go.

> Unfortunately I cannot boot from my SCSI CD-ROM after configuring the
> host adapter BIOS and drive to do so, so I was unable to boot a
> live CD and test legacy hardware support. No BIOS support for USB
> booting, either. I have found a full commercially-prepared set of
> Debian 5 CDs which should include the Initio driver I need, so I am
> trying to figure out how to install from these CDs through a hard
> drive-based install located in the same partition  where I want Debian
> 5 installed.  Cue Debian install guide and FAQ.
> 
> I have initialized a 3.3 MB ext3 root partition for Debian 5 and
> downloaded the hd-media versions of vmlinuz, initrd.gz, boot.img.gz and
> a cd ISO from the official Debian archives. 

The 3.3 MB root partition isn't required. I suppose you could use it,
but it appears to me to complicate things.

boot.img.gz isn't needed either.

> 1) If I install this kernel and iso image in my Debian 5 root 
> partition with lilo or grub, I should automatically launch the Debian 5
> installer after booting this partition, correct?

I'd put vmlinuz and initrd.gz in /boot/ and the cd ISO in /, a place
where d-i is likely to find it when it looks for it. d-i can also locate
the ISO if it is on a USB stick.

You didn't say what your existing bootloader is. GRUB Legacy? If so. you
write a stanza in its configuration file giving the locations of vmlinuz
and initrd.gz so you can boot the kernel.

> 2) How do I go about creating the rudimentary file system I need be
> able to install lilo or grub on the clean root partition - without
> what subdirectories and executables do I  need and where do I find
> them without a working Debian 5 system to clone?
> 
> 
> 3a) If I can launch the Debian Installer this way, will it allow me to
> manually switch package sources from Debian servers to my CD-ROM (which
> presumably I can mount once the installer has loaded the Initio SCSI
> driver module.)?

This could be done after you have installed from the cd ISO and have
booted into the new system.

> 3b) If not, will the installer pull packages from my CDs if I replace
> the hd-media version of the cd ISO image with the CD version of the
> cd #1 ISO image?

You can certainly use cd #1 but, never having done it, I'm not certain
about how d-i deals with the other CDs.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130717205657.gj25...@copernicus.demon.co.uk

clean hd-media install onto hard drive partition of old SCSI box

[sar0113]

Hello,

I want to install a recent Debian distribution on a clean partition of
a stand-alone SCSI box which runs multiple legacy OSes, including
Woody. I did not upgrade Woody because driver support for my Initio
SCSI host adapter was problematic with supplied 2.6 kernels for
several years, but apparently resolved according to a Debian bug
report.

Unfortunately I cannot boot from my SCSI CD-ROM after configuring the
host adapter BIOS and drive to do so, so I was unable to boot a
live CD and test legacy hardware support. No BIOS support for USB
booting, either. I have found a full commercially-prepared set of
Debian 5 CDs which should include the Initio driver I need, so I am
trying to figure out how to install from these CDs through a hard
drive-based install located in the same partition  where I want Debian
5 installed.  Cue Debian install guide and FAQ.

I have initialized a 3.3 MB ext3 root partition for Debian 5 and
downloaded the hd-media versions of vmlinuz, initrd.gz, boot.img.gz and
a cd ISO from the official Debian archives. 

1) If I install this kernel and iso image in my Debian 5 root 
partition with lilo or grub, I should automatically launch the Debian 5
installer after booting this partition, correct?


2) How do I go about creating the rudimentary file system I need be
able to install lilo or grub on the clean root partition - without
what subdirectories and executables do I  need and where do I find
them without a working Debian 5 system to clone?


3a) If I can launch the Debian Installer this way, will it allow me to
manually switch package sources from Debian servers to my CD-ROM (which
presumably I can mount once the installer has loaded the Initio SCSI
driver module.)?

3b) If not, will the installer pull packages from my CDs if I replace
the hd-media version of the cd ISO image with the CD version of the
cd #1 ISO image?

Thanks for any pointers.


 Please do not add my name or address to mailing lists 
 nor distribute them without my consent.  Thank you.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130717191827.ga1...@nc.rr.com

Re: insmod: error inserting /lib/modules/2.6.32-5-486/kernel/drivers/scsi/aacraid/aacraid.ko : -1 File exists

[Curt]

On 2012-05-03, Joey L  wrote:
>
> insmod: error inserting
> /lib/modules/2.6.32-5-486/kernel/drivers/scsi/aacraid/aacraid.ko : -1
> File exists

Does it (is it already loaded)?

lsmod | grep aacraid


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnjqkd1a.29r.cu...@einstein.electron.org

insmod: error inserting /lib/modules/2.6.32-5-486/kernel/drivers/scsi/aacraid/aacraid.ko : -1 File exists

[Joey L]

i downloaded the new aacraid driver from ibm.
- I need to install it during debian install - but getting an error -

insmod: error inserting
/lib/modules/2.6.32-5-486/kernel/drivers/scsi/aacraid/aacraid.ko : -1
File exists


I have no clue what this means -- here are the instructions :( it
happened when i run insmod below)

---Is there a way i can create a debian dvd with the new driver ???
thanks



This procedure installs the aacraid driver while installing Debian
Server 6.0 32bit

1. Copy "aacraid.ko-PRE_MOD" and "aacraid.ko-POST_MOD" to a floppy
disk or USB flash.

2. Start installing Debian 6.0 Linux by booting from the installation
DVD and select "Graphical Install" option,
   Press CTRL+ALT+F2 to switch to console2 while Debian detects the network.

3. Insert your USB key or floopy disk

4. fdisk -l   (scan for device, assume if USB drive is assigned to /dev/sda1)

5. Type the following commands:
# mkdir /mnt2  /AACRAID
# mount /dev/sda1 /mnt2
# cp -R /mnt2/* /AACRAID
# umount /mnt2

6. *** Please remove the USB flash before the insmod command ***

7. # cp -f /AACRAID/aacraid.ko-PRE_MOD
/lib/modules/2.6.32-5-486/kernel/drivers/scsi/aacraid/aacraid.ko
   # insmod /lib/modules/2.6.32-5-486/kernel/drivers/scsi/aacraid/aacraid.ko

8. Press CTRL+ALT+F5 to return to installer. Continue the installation as usual.

9. Do not reboot after the installation is complete. Press CTRL+ALT+F2 to
   switch to console 2 again.

10. Type the following commands:
# cp -f /AACRAID/aacraid.ko-POST_MOD
/target/lib/modules/2.6.32-5-amd64/kernel/drivers/scsi/aacraid/aacraid.ko
# chroot /target
# /sbin/depmod  -a  2.6.32-5-amd64
# update-initramfs -u -v
# exit

11. Press CTRL+ALT+F5 to return to the installer. Reboot to complete
the installation.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAK3ER7sVgVyP4yggUdxORBgbp=egw+gnzx+8v+ogo_jlyfl...@mail.gmail.com

Re: scsi Install problem

[Camaleón]

On Wed, 04 Apr 2012 08:20:08 -0700, cletusjenkins wrote:

(...)

> scsi host0: error: init_state 0x1f, warn 0xfffe, error 0x0 firmware:
> requisting advansys/mcode.bin Failed to load image "advansys/mcode.bin"
> err -2 scsi 0:0:0:0: SCSI bus reset started...
> 
> The internet seems to say this is a firmware issue, and suggests
> obtaining mcode.bin and place it where debian expects it to be, but I
> don't know where that is (on my laptop I assume
> /lib/modules/2.6.32-5-686/kernel/drivers/scsi/), 

I think the correct place is "/lib/firmware/advansys/mcode.bin".

> but it would be a little hard to place it since this is the install CD
> and not an existing system. 

(...)

You may need to install the "firmware-linux-nonfree" package.

More info on how to proceed:

http://wiki.debian.org/Firmware

Greetings,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/jlhrd1$j6s$1...@dough.gmane.org

Re: scsi Install problem

[Darac Marjal]

On Wed, Apr 04, 2012 at 08:20:08AM -0700, cletusjenkins wrote:
> I am trying to reinstall an older machine with an Advansys SCSI host adapter 
> and not having much luck. I have two of the same model adapters and both have 
> the same issues. When I boot without either in the machine, it gets well past 
> my error/stopping point.
> 
> I'm booting off of the CD 1, I downloaded it 2 days ago, its worked with 
> another box I reinstalled yesterday (replacing a sarge install, cleaning out 
> the basement). I've tried different options expert install and rescue, etc 
> and they all seem to go awry just after the kernel boots, it recognizes all 
> the hardware including the scsi adapter. But at some point there is a scsi 
> bus reset warning then it never seems to complete, it just keeps resetting 
> and failing. The errors messages cycle and repeat:
> 
> scsi host0: error: init_state 0x1f, warn 0xfffe, error 0x0
> firmware: requisting advansys/mcode.bin
> Failed to load image "advansys/mcode.bin" err -2
> scsi 0:0:0:0: SCSI bus reset started...
> 
> The internet seems to say this is a firmware issue, and suggests obtaining 
> mcode.bin and place it where debian expects it to be, but I don't know where 
> that is (on my laptop I assume 
> /lib/modules/2.6.32-5-686/kernel/drivers/scsi/), but it would be a little 
> hard to place it since this is the install CD and not an existing system. Can 
> I mount the CD image and just add the file and burn it to disk? Would I put 
> the file in a directory or would the installer expect it to be bundled in a 
> deb/udeb file? Even so the internet also seems skeptical that this will 
> actually work, but I couldn't find any reason why that is. Thanks for any 
> pointers. I'm hoping to build a box with every type of scsi interface from 
> ultra2 LVD down to this advansys with an internal 50-pin connector and 
> external 25 pin D-sub connector. I can finally go through all my old scsi 
> hard drives and then actually throw something away!

Yes, it's a firmware issue. See http://wiki.debian.org/Firmware for full
details.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120404155957.ga18...@darac.org.uk

scsi Install problem

[cletusjenkins]

I am trying to reinstall an older machine with an Advansys SCSI host adapter 
and not having much luck. I have two of the same model adapters and both have 
the same issues. When I boot without either in the machine, it gets well past 
my error/stopping point.

I'm booting off of the CD 1, I downloaded it 2 days ago, its worked with 
another box I reinstalled yesterday (replacing a sarge install, cleaning out 
the basement). I've tried different options expert install and rescue, etc and 
they all seem to go awry just after the kernel boots, it recognizes all the 
hardware including the scsi adapter. But at some point there is a scsi bus 
reset warning then it never seems to complete, it just keeps resetting and 
failing. The errors messages cycle and repeat:

scsi host0: error: init_state 0x1f, warn 0xfffe, error 0x0
firmware: requisting advansys/mcode.bin
Failed to load image "advansys/mcode.bin" err -2
scsi 0:0:0:0: SCSI bus reset started...

The internet seems to say this is a firmware issue, and suggests obtaining 
mcode.bin and place it where debian expects it to be, but I don't know where 
that is (on my laptop I assume /lib/modules/2.6.32-5-686/kernel/drivers/scsi/), 
but it would be a little hard to place it since this is the install CD and not 
an existing system. Can I mount the CD image and just add the file and burn it 
to disk? Would I put the file in a directory or would the installer expect it 
to be bundled in a deb/udeb file? Even so the internet also seems skeptical 
that this will actually work, but I couldn't find any reason why that is. 
Thanks for any pointers. I'm hoping to build a box with every type of scsi 
interface from ultra2 LVD down to this advansys with an internal 50-pin 
connector and external 25 pin D-sub connector. I can finally go through all my 
old scsi hard drives and then actually throw something away!

-- clet
debian is my main squeeze



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1367df6e203.6760854228242017363.-7788772350289868...@zoho.com

Re: aacraid and smp kernel: SCSI hang

[Joey L]

did you have any issues with the video on the ibm 3650 ?
I am having a wierd problem where i disabled the gdm3 from loading -
now i can not get the text console on the server.
You know the login screen in text mode on the server is not visiable -
but can login to server from other workstations.
I thought i sent you this email before...but do not knwo if you got it.
thanks
mjh

On Wed, Mar 14, 2012 at 9:58 AM, Joey L  wrote:
> thanks a bunch!
>
> On Wed, Mar 14, 2012 at 9:46 AM, Kostas Magkos  wrote:
>> If you are running squeeze you shouldn't be searching for the module.
>>
>> What you see on this webpage is the Adaptec Storage Manager (ASM) which
>> is the software to manage the controller. The aacraid module (which is
>> needed for the kernel to access the controller and thus the raid
>> containers) should be included in the stock squeeze kernel. At least
>> this is the case for our 2410sa. I believe both controllers (2820sa and
>> 2410sa) are accessed through the same module, but I'm not sure. You
>> should check.
>>
>> A good place for getting help and searching for solutions is the Adaptec
>> Support Knowledgebase at:
>> http://ask.adaptec.com
>>
>> As a matter of fact, I did use ASK quite recently (last summer) and
>> while our controller is really old they, worked with me and helped me
>> figure out what was messing up our setup. The support guy even gave me a
>> link to download a version of ASM that wasn't in the download page of
>> the 2410sa, compatible with debian.
>>
>> Regards,
>> Kostas
>>
>> Joey L wrote:
>>> thanks for the quick reply back - do you know where i can get the
>>> latest module for debian squeeze x86 ?
>>> There are so many on the site and that i have found and do not know
>>> which is which..
>>> http://www.adaptec.com/en-us/downloads/storage_manager/sm/productid=aar-2820sa&dn=adaptec+serial+ata+ii+raid+2820sa.html
>>>
>>> thanks
>>>
>>> On Wed, Mar 14, 2012 at 7:01 AM, Kostas Magkos  
>>> wrote:
>>>
>>>> Hi there,
>>>>
>>>> I've scrolled back my notes and found that this was an issue with sarge
>>>> and aacraid module prior to 1.1.5.-2400. This was solved as soon as we
>>>> upgraded to etch (etch comes with aacraid 1.1.5-2409). As I can recall,
>>>> the system had a rather arbitrary behaviour while running sarge: most of
>>>> the times it would fail to boot, but sometimes it would reach the login
>>>> prompt and then run steadily until the next reboot.
>>>>
>>>> For the record I can't remember getting any answers for this.
>>>>
>>>> Hope that helps a bit,
>>>> Kostas
>>>>
>>>> Joey L wrote:
>>>>
>>>>> hi..i am getting the same issue on ibm 3650 - did you get any answers
>>>>> or found solution ?
>>>>>
>>>>> thanks
>>>>> mj
>>>>>
>>>>> On Wed, Dec 5, 2007 at 5:09 AM, Kostas Magkos  
>>>>> wrote:
>>>>>
>>>>>
>>>>>> Greetings all,
>>>>>>
>>>>>> Our main server is an Opteron system with an Adaptec SATA RAID 2410SA
>>>>>> controller and 4x 250GB Seagate Barracuda disks attached to it, forming
>>>>>> a RAID-5 and a RAID-0 container. The system is running sarge with the
>>>>>> latest 2.6.8 kernel (2.6.8-13-amd64-k8).
>>>>>>
>>>>>> We recently upgraded the server with a second Opteron CPU. When we tried
>>>>>> to boot the system with the SMP kernel it gave the following messages
>>>>>> just after the login prompt and hung:
>>>>>>
>>>>>> Nov 9 09:52:58 myhost kernel: aacraid: Host adapter reset request. SCSI
>>>>>> hang ?
>>>>>> Nov 9 09:52:58 myhost kernel: aacraid: Host adapter reset request. SCSI
>>>>>> hang ?
>>>>>> Nov 9 09:53:32 myhost kernel: aacraid: SCSI bus appears hung
>>>>>>
>>>>>> Sarge 2.6.8 kernels contain aacraid 1.1.2-lk2. I managed to compile and
>>>>>> install version 1.1.5-2400 (downloaded from Adaptec's site) but without
>>>>>> any luck, the system still hangs.
>>>>>>
>>>>>> Please note that aacraid 1.1.5-2400 has been used in the single CPU
>>>>>> system (i.e. before the addition of the second CPU) for quite some time,
>>>>

Re: scsi device files not created when called for

[Morten Bo Johansen]

Camaleón  wrote:
> On Sat, 11 Feb 2012 14:06:40 +0100, Morten Bo Johansen wrote:

>> In the latter case, which package should I report against?

> I'd say "libsane".

I think I'll go for udev. Once the scanner is attached to to a
scsi device file, then the appropriate module should be loaded
and the files created.

>> Some info:

>>~/ % uname -a
>>Linux gatsby 3.2.0-1-686-pae #1 SMP Sun Feb 5 23:52:49 UTC 2012 i686
>>GNU/Linux

>>package "udev" is version 175-3

> You're on sid, right?

It is a mixed testing/unstable system. Thanks for your attention.

Morten



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnjjd748.n9s@gatsby.mbjnet.dk

Re: scsi device files not created when called for

[Camaleón]

On Sat, 11 Feb 2012 14:06:40 +0100, Morten Bo Johansen wrote:

> My scanner suddenly stopped working. It is connected through firewire
> and when I turn it on, the firewire devices are created:

(...)

> My Epson scanner is thus recognized. However, the scanner is also being
> attached to a scsi device, but the scsi device files are not being
> created automatically under /dev/ which means that xsane will not see
> it. When I ran:
> 
>~/ % sudo modprobe sg
>
> manually, the scsi device files are created as /dev/sg0 etc. and my
> scanner now works again with xsane.
> 
> I could load the "sg" module from /etc/modules, but I do not think it
> should be necessary.
> 
> I wonder if there is something wrong with my setup, since I need to
> manually load the scsi generic driver, or if this is a bug that I should
> report? 

As it was not necessary to manually load the generic scsi before, it 
shouldn't be needed now so could be an error, maybe an "udev" rule wrong 
or missing :-?

> In the latter case, which package should I report against?

I'd say "libsane".
  
> Some info:
> 
>~/ % uname -a
>Linux gatsby 3.2.0-1-686-pae #1 SMP Sun Feb 5 23:52:49 UTC 2012 i686
>GNU/Linux
> 
>package "udev" is version 175-3

You're on sid, right?

Greetings,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/jh63u7$qqo$1...@dough.gmane.org

scsi device files not created when called for

[Morten Bo Johansen]

Hi,

My scanner suddenly stopped working. It is connected through firewire and
when I turn it on, the firewire devices are created:

   ~/ % dmesg | tail -6
   [ 8377.031246] firewire_core: phy config: card 0, new root=ffc1, gap_count=5
   [ 8377.529022] scsi7 : SBP-2 IEEE-1394
   [ 8377.529102] firewire_sbp2: fw1.0: 127s mgt_ORB_timeout limited to 40s
   [ 8377.529108] firewire_core: created device fw1: GUID 484ee815, S400
   [ 8377.728590] firewire_sbp2: fw1.0: logged in to LUN  (0 retries)
   [ 8377.729957] scsi 7:0:0:0: Processor EPSONGT-X900  
1.06 PQ: 0 ANSI: 4

My Epson scanner is thus recognized. However, the scanner is also being
attached to a scsi device, but the scsi device files are not being
created automatically under /dev/ which means that xsane will not see it.
When I ran:

   ~/ % sudo modprobe sg
   
manually, the scsi device files are created as /dev/sg0 etc. and my
scanner now works again with xsane.

I could load the "sg" module from /etc/modules, but I do not think it
should be necessary.

I wonder if there is something wrong with my setup, since I need to
manually load the scsi generic driver, or if this is a bug that I should
report? In the latter case, which package should I report against?
 

Some info:

   ~/ % uname -a
   Linux gatsby 3.2.0-1-686-pae #1 SMP Sun Feb 5 23:52:49 UTC 2012 i686 
GNU/Linux

   package "udev" is version 175-3


Thanks,

Morten



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnjjcpv2.8b4@gatsby.mbjnet.dk

Re: kernel option for scsi emulation

[Hugo Vanwoerkom]

On Fri, 12 Nov 2010 14:10:48 -0600, Hugo Vanwoerkom wrote:


On 11/12/2010 01:49 PM, Camaleón wrote:


(...)


Compare both "lsmod | grep ata" outputs.



Good suggestion:

h...@debian:/$ grep ata 11.2.6.32-5-686.lsmod 
ata_generic 2047  0
libata115745  3 ata_generic,sata_via,pata_via 
pata_via5701  4

sata_via5608  0
scsi_mod  101401  6 ums_cypress,usb_storage,sg,sr_mod,sd_mod,libata 


If that's correct, then I'm missing :-)

kernel 2.6.32 was not the one using legacy driver _but_ it is
loading it (pata_via).

h...@debian:/$ grep ata 11.2.6.36-hvw.lsmod

ata_generic 2075  0
libata116648  2 ata_generic,sata_via 
sata_via5380  0

scsi_mod  100151  5 sg,sd_mod,ums_cypress,usb_storage,libata


So both kernels have libata, but only 2.6.32-5-686 has pata_via and
sr_mod.


Yep, but 2.6.32 was using "/dev/sd*" nomenaclature for Maxtor disk >:-?

2.6.32-5-686
/dev/sda1: LABEL="6Y080P0.01" 
UUID="1205def1-2141-4b3a-97d0-0b94ca1c4ff2" TYPE="ext2"
/dev/sda5: LABEL="6Y080P0.05" 
UUID="dc767bc6-ebe4-4dfb-a8f1-739709598dc7" TYPE="ext2"
/dev/sda6: LABEL="6Y080P0.06" 
UUID="a7cfe5f2-b136-4a73-ac8a-f3e2121102c8" TYPE="ext2"
/dev/sda7: LABEL="6Y080P0.07" 
UUID="45ee8af8-c443-42d4-ae59-6f68e33932e8" TYPE="ext2"

/dev/sda8: LABEL="win_D" UUID="4131-BA32" TYPE="vfat"
/dev/sda9: LABEL="6Y080P0.09" 
UUID="5a09faf0-6f8e-4c72-a23b-46fe963754ef" TYPE="swap"
/dev/sda10: LABEL="6Y080P0.10" 
UUID="66c1d026-1e4c-4392-8aa0-e0d9f2cb4277" TYPE="ext2"


2.6.36-hvw
/dev/hda1: LABEL="6Y080P0.01" 
UUID="1205def1-2141-4b3a-97d0-0b94ca1c4ff2" TYPE="ext2"
/dev/hda5: LABEL="6Y080P0.05" 
UUID="dc767bc6-ebe4-4dfb-a8f1-739709598dc7" TYPE="ext2"
/dev/hda6: LABEL="6Y080P0.06" 
UUID="a7cfe5f2-b136-4a73-ac8a-f3e2121102c8" TYPE="ext2"
/dev/hda7: LABEL="6Y080P0.07" 
UUID="45ee8af8-c443-42d4-ae59-6f68e33932e8" TYPE="ext2"

/dev/hda8: LABEL="win_D" UUID="4131-BA32" TYPE="vfat"
/dev/hda9: LABEL="6Y080P0.09" 
UUID="5a09faf0-6f8e-4c72-a23b-46fe963754ef" TYPE="swap"
/dev/hda10: LABEL="6Y080P0.10" 
UUID="66c1d026-1e4c-4392-8aa0-e0d9f2cb4277" TYPE="ext2"


Is that right?

Right


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4cdeb0e5.5090...@care2.com

Re: kernel option for scsi emulation

[Camaleón]

On Fri, 12 Nov 2010 14:10:48 -0600, Hugo Vanwoerkom wrote:

> On 11/12/2010 01:49 PM, Camaleón wrote:

(...)

>> Compare both "lsmod | grep ata" outputs.
>>
>>
> Good suggestion:
> 
> h...@debian:/$ grep ata 11.2.6.32-5-686.lsmod 
> ata_generic 2047  0
> libata115745  3 ata_generic,sata_via,pata_via 
> pata_via5701  4
> sata_via5608  0
> scsi_mod  101401  6 
> ums_cypress,usb_storage,sg,sr_mod,sd_mod,libata 

If that's correct, then I'm missing :-)

kernel 2.6.32 was not the one using legacy driver _but_ it is 
loading it (pata_via).

h...@debian:/$ grep ata 11.2.6.36-hvw.lsmod 
> ata_generic 2075  0
> libata116648  2 ata_generic,sata_via 
> sata_via5380  0
> scsi_mod  100151  5 sg,sd_mod,ums_cypress,usb_storage,libata
> 
> 
> So both kernels have libata, but only 2.6.32-5-686 has pata_via and
> sr_mod.

Yep, but 2.6.32 was using "/dev/sd*" nomenaclature for Maxtor disk >:-?

2.6.32-5-686
/dev/sda1: LABEL="6Y080P0.01" UUID="1205def1-2141-4b3a-97d0-0b94ca1c4ff2" 
TYPE="ext2"
/dev/sda5: LABEL="6Y080P0.05" UUID="dc767bc6-ebe4-4dfb-a8f1-739709598dc7" 
TYPE="ext2"
/dev/sda6: LABEL="6Y080P0.06" UUID="a7cfe5f2-b136-4a73-ac8a-f3e2121102c8" 
TYPE="ext2"
/dev/sda7: LABEL="6Y080P0.07" UUID="45ee8af8-c443-42d4-ae59-6f68e33932e8" 
TYPE="ext2"
/dev/sda8: LABEL="win_D" UUID="4131-BA32" TYPE="vfat"
/dev/sda9: LABEL="6Y080P0.09" UUID="5a09faf0-6f8e-4c72-a23b-46fe963754ef" 
TYPE="swap"
/dev/sda10: LABEL="6Y080P0.10" UUID="66c1d026-1e4c-4392-8aa0-e0d9f2cb4277" 
TYPE="ext2"

2.6.36-hvw
/dev/hda1: LABEL="6Y080P0.01" UUID="1205def1-2141-4b3a-97d0-0b94ca1c4ff2" 
TYPE="ext2" 
/dev/hda5: LABEL="6Y080P0.05" UUID="dc767bc6-ebe4-4dfb-a8f1-739709598dc7" 
TYPE="ext2"
/dev/hda6: LABEL="6Y080P0.06" UUID="a7cfe5f2-b136-4a73-ac8a-f3e2121102c8" 
TYPE="ext2"
/dev/hda7: LABEL="6Y080P0.07" UUID="45ee8af8-c443-42d4-ae59-6f68e33932e8" 
TYPE="ext2"
/dev/hda8: LABEL="win_D" UUID="4131-BA32" TYPE="vfat"
/dev/hda9: LABEL="6Y080P0.09" UUID="5a09faf0-6f8e-4c72-a23b-46fe963754ef" 
TYPE="swap"
/dev/hda10: LABEL="6Y080P0.10" UUID="66c1d026-1e4c-4392-8aa0-e0d9f2cb4277" 
TYPE="ext2"

Is that right?

Greetings,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/pan.2010.11.12.21.13...@gmail.com

Re: kernel option for scsi emulation

[Hugo Vanwoerkom]

On 11/12/2010 02:10 PM, Hugo Vanwoerkom wrote:

On 11/12/2010 01:49 PM, Camaleón wrote:

On Fri, 12 Nov 2010 12:06:16 -0600, Hugo Vanwoerkom wrote:


I have 2 kernels: Debian's 2.6.32-5-686 and my own 2.6.36-hvw.

The former no longer has /dev/hd* the latter does as shown by blkid. [1]
blkid for 2.6.32-5-686 and [2] for 2.6.36-hvw.

What kernel option is responsible for that? Obviously I don't have that
set in 2.6.36-hvw.


(...)

In brief, if I got it correctly, your Maxtor hard disk (IDE) is being
detected as "/dev/hd*" in 2.6.36 (using legacy pata module) and as "/dev/
sd*" in 2.6.32 (using new libata module).

Back to days I was using openSUSE, pata modules were loaded by telling
the kernel "hwprobe=-modules.pata" at GRUB prompt (or by stating so in
menu.lst). Maybe you are inadvertenly loading legacy pata module or you
have compiled the kernel with that flag switched on :-?

Compare both "lsmod | grep ata" outputs.



Good suggestion:

h...@debian:/$ grep ata 11.2.6.32-5-686.lsmod
ata_generic 2047 0
libata 115745 3 ata_generic,sata_via,pata_via
pata_via 5701 4
sata_via 5608 0
scsi_mod 101401 6 ums_cypress,usb_storage,sg,sr_mod,sd_mod,libata
h...@debian:/$ grep ata 11.2.6.36-hvw.lsmod
ata_generic 2075 0
libata 116648 2 ata_generic,sata_via
sata_via 5380 0
scsi_mod 100151 5 sg,sd_mod,ums_cypress,usb_storage,libata


So both kernels have libata, but only 2.6.32-5-686 has pata_via and sr_mod.



lsmod | grep sr_mod
h...@debian:/usr/src/linux-2.6.36$ grep CONFIG_BLK_DEV_SR .config
CONFIG_BLK_DEV_SR=m

that is the SCSI CDrom module and that is set in the kernel.
Don't know why it does not show up in lsmod.

That leaves the pata_via module and that indeed is not set.

So the difference in getting /dev/hd* is solely due to the absence of 
the pata_via module?


Hugo


















--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/ibk7un$pk...@dough.gmane.org

Re: kernel option for scsi emulation

[Hugo Vanwoerkom]

On 11/12/2010 02:10 PM, Hugo Vanwoerkom wrote:

On 11/12/2010 01:49 PM, Camaleón wrote:

On Fri, 12 Nov 2010 12:06:16 -0600, Hugo Vanwoerkom wrote:


I have 2 kernels: Debian's 2.6.32-5-686 and my own 2.6.36-hvw.

The former no longer has /dev/hd* the latter does as shown by blkid. [1]
blkid for 2.6.32-5-686 and [2] for 2.6.36-hvw.

What kernel option is responsible for that? Obviously I don't have that
set in 2.6.36-hvw.


(...)

In brief, if I got it correctly, your Maxtor hard disk (IDE) is being
detected as "/dev/hd*" in 2.6.36 (using legacy pata module) and as "/dev/
sd*" in 2.6.32 (using new libata module).

Back to days I was using openSUSE, pata modules were loaded by telling
the kernel "hwprobe=-modules.pata" at GRUB prompt (or by stating so in
menu.lst). Maybe you are inadvertenly loading legacy pata module or you
have compiled the kernel with that flag switched on :-?

Compare both "lsmod | grep ata" outputs.



Good suggestion:

h...@debian:/$ grep ata 11.2.6.32-5-686.lsmod
ata_generic 2047 0
libata 115745 3 ata_generic,sata_via,pata_via
pata_via 5701 4
sata_via 5608 0
scsi_mod 101401 6 ums_cypress,usb_storage,sg,sr_mod,sd_mod,libata
h...@debian:/$ grep ata 11.2.6.36-hvw.lsmod
ata_generic 2075 0
libata 116648 2 ata_generic,sata_via
sata_via 5380 0
scsi_mod 100151 5 sg,sd_mod,ums_cypress,usb_storage,libata


So both kernels have libata, but only 2.6.32-5-686 has pata_via and sr_mod.



lsmod | grep sr_mod
h...@debian:/usr/src/linux-2.6.36$ grep CONFIG_BLK_DEV_SR .config
CONFIG_BLK_DEV_SR=m

that is the SCSI CDrom module and that is set in the kernel.
Don't know why it does not show up in lsmod.

That leaves the pata_via module and that indeed is not set.

So the difference in getting /dev/hd* is solely due to the absence of 
the pata_via module?


Hugo


















--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/ibk847$q4...@dough.gmane.org

Re: kernel option for scsi emulation

[Hugo Vanwoerkom]

On 11/12/2010 01:49 PM, Camaleón wrote:

On Fri, 12 Nov 2010 12:06:16 -0600, Hugo Vanwoerkom wrote:


I have 2 kernels: Debian's 2.6.32-5-686 and my own 2.6.36-hvw.

The former no longer has /dev/hd* the latter does as shown by blkid. [1]
blkid for 2.6.32-5-686 and [2] for 2.6.36-hvw.

What kernel option is responsible for that? Obviously I don't have that
set in 2.6.36-hvw.


(...)

In brief, if I got it correctly, your Maxtor hard disk (IDE) is being
detected as "/dev/hd*" in 2.6.36 (using legacy pata module) and as "/dev/
sd*" in 2.6.32 (using new libata module).

Back to days I was using openSUSE, pata modules were loaded by telling
the kernel "hwprobe=-modules.pata" at GRUB prompt (or by stating so in
menu.lst). Maybe you are inadvertenly loading legacy pata module or you
have compiled the kernel with that flag switched on :-?

Compare both "lsmod | grep ata" outputs.



Good suggestion:

h...@debian:/$ grep ata 11.2.6.32-5-686.lsmod
ata_generic 2047  0
libata115745  3 ata_generic,sata_via,pata_via
pata_via5701  4
sata_via5608  0
scsi_mod  101401  6 
ums_cypress,usb_storage,sg,sr_mod,sd_mod,libata

h...@debian:/$ grep ata 11.2.6.36-hvw.lsmod
ata_generic 2075  0
libata116648  2 ata_generic,sata_via
sata_via5380  0
scsi_mod  100151  5 sg,sd_mod,ums_cypress,usb_storage,libata


So both kernels have libata, but only 2.6.32-5-686 has pata_via and sr_mod.

Hugo



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/ibk709$lc...@dough.gmane.org

Re: kernel option for scsi emulation

[Camaleón]

On Fri, 12 Nov 2010 12:06:16 -0600, Hugo Vanwoerkom wrote:

> I have 2 kernels: Debian's 2.6.32-5-686 and my own 2.6.36-hvw.
> 
> The former no longer has /dev/hd* the latter does as shown by blkid. [1]
> blkid for 2.6.32-5-686 and [2] for 2.6.36-hvw.
> 
> What kernel option is responsible for that? Obviously I don't have that
> set in 2.6.36-hvw.

(...)

In brief, if I got it correctly, your Maxtor hard disk (IDE) is being 
detected as "/dev/hd*" in 2.6.36 (using legacy pata module) and as "/dev/
sd*" in 2.6.32 (using new libata module).

Back to days I was using openSUSE, pata modules were loaded by telling 
the kernel "hwprobe=-modules.pata" at GRUB prompt (or by stating so in 
menu.lst). Maybe you are inadvertenly loading legacy pata module or you 
have compiled the kernel with that flag switched on :-?

Compare both "lsmod | grep ata" outputs.

Greetings,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/pan.2010.11.12.19.49...@gmail.com

kernel option for scsi emulation

[Hugo Vanwoerkom]

Hi,

I have 2 kernels: Debian's 2.6.32-5-686 and my own 2.6.36-hvw.

The former no longer has /dev/hd* the latter does as shown by blkid. [1] 
blkid for 2.6.32-5-686 and [2] for 2.6.36-hvw.


What kernel option is responsible for that? Obviously I don't have that 
set in 2.6.36-hvw.


Thanks.

Hugo

[1]
/dev/sda1: LABEL="6Y080P0.01" 
UUID="1205def1-2141-4b3a-97d0-0b94ca1c4ff2" TYPE="ext2"
/dev/sda5: LABEL="6Y080P0.05" 
UUID="dc767bc6-ebe4-4dfb-a8f1-739709598dc7" TYPE="ext2"
/dev/sda6: LABEL="6Y080P0.06" 
UUID="a7cfe5f2-b136-4a73-ac8a-f3e2121102c8" TYPE="ext2"
/dev/sda7: LABEL="6Y080P0.07" 
UUID="45ee8af8-c443-42d4-ae59-6f68e33932e8" TYPE="ext2"
/dev/sdb1: LABEL="ST380011A.01" 
UUID="1ab511e2-8e17-460e-91e2-a46d85c55654" TYPE="ext2"
/dev/sdb2: LABEL="ST380011A.02" 
UUID="4c899a3a-4a3c-4910-aa35-a86a24e9c036" TYPE="ext2"
/dev/sdb3: LABEL="ST380011A.03" 
UUID="4c899a3a-4a3c-4910-aa35-a86a24e9c036" TYPE="ext2"
/dev/sdb5: LABEL="ST380011A.05" 
UUID="3ff336b4-c16e-43c4-868a-b50dd22ebe59" TYPE="ext2"
/dev/sdb6: LABEL="ST380011A.06" 
UUID="1d4e5f26-36a2-49d2-840d-83206ddedb44" TYPE="ext2"
/dev/sdb7: LABEL="ST380011A.07" 
UUID="5bf6de45-0c3a-453c-9faf-34905b1cc654" TYPE="ext2"

/dev/sda8: LABEL="win_D" UUID="4131-BA32" TYPE="vfat"
/dev/sda9: LABEL="6Y080P0.09" 
UUID="5a09faf0-6f8e-4c72-a23b-46fe963754ef" TYPE="swap"
/dev/sda10: LABEL="6Y080P0.10" 
UUID="66c1d026-1e4c-4392-8aa0-e0d9f2cb4277" TYPE="ext2"
/dev/sdc1: LABEL="wd80_0jd-60.01" 
UUID="51c42282-286b-4675-874d-a91a71b6e390" TYPE="ext2"
/dev/sdc2: LABEL="wd80_0jd-60.02" 
UUID="ca8ce431-52ae-4368-8e55-a93085d39d09" TYPE="ext2"
/dev/sdc3: LABEL="wd80_0jd-60.03" 
UUID="276a49d4-e31c-4b5e-aecc-e25558dd6b2c" TYPE="ext2"
/dev/sdc5: LABEL="wd80_0jd-60.05" 
UUID="62f0736f-460e-4b2d-90e9-a165f935ff66" TYPE="ext2"
/dev/sdc6: LABEL="wd80_0jd-60.06" 
UUID="c1301727-ecc3-480f-8749-e5326f2e6dfe" TYPE="ext2"
/dev/sdc7: LABEL="wd80_0jd-60.07" 
UUID="7c5f6382-76dc-40a6-9916-234b6797ad34" TYPE="ext2"

/dev/sdd1: SEC_TYPE="msdos" LABEL="GLADYS" UUID="38B9-234F" TYPE="vfat"
/dev/sde1: LABEL="WD16_00AAJB.01" 
UUID="b2310659-60e2-4af2-8211-aae960c18bce" TYPE="ext2"
/dev/sde2: LABEL="WD16_00AAJB.02" 
UUID="257fbb4c-4526-4da0-a287-4f6b93c3ca87" TYPE="ext2"
/dev/sde3: LABEL="WD16_00AAJB.03" 
UUID="56b87482-73bf-4343-af80-4ddd98c1e377" TYPE="ext2"
/dev/sde5: LABEL="WD16_00AAJB.05" 
UUID="cd0db4e9-1ef7-49fb-afa9-415cc83da95c" TYPE="ext2"
/dev/sde6: LABEL="WD16_00AAJB.06" 
UUID="d8701e3c-8357-4069-9e96-66ee307d69aa" TYPE="ext2"
/dev/sde7: LABEL="WD16_00AAJB.07" 
UUID="89f34b01-5d68-4bb6-927f-ee5b6b7c0a46" TYPE="ext2"
/dev/sde8: LABEL="WD16_00AAJB.08" 
UUID="4fbe9d8e-2efb-4ef8-8189-a9fb494b347d" TYPE="ext2"


[2]
/dev/sda1: LABEL="wd80_0jd-60.01" 
UUID="51c42282-286b-4675-874d-a91a71b6e390" TYPE="ext2"
/dev/sda5: LABEL="wd80_0jd-60.05" 
UUID="62f0736f-460e-4b2d-90e9-a165f935ff66" TYPE="ext2"
/dev/sda6: LABEL="wd80_0jd-60.06" 
UUID="c1301727-ecc3-480f-8749-e5326f2e6dfe" TYPE="ext2"
/dev/sda7: LABEL="wd80_0jd-60.07" 
UUID="7c5f6382-76dc-40a6-9916-234b6797ad34" TYPE="ext2"
/dev/sdb1: LABEL="WD16_00AAJB.01" 
UUID="b2310659-60e2-4af2-8211-aae960c18bce" TYPE="ext2"
/dev/sdb2: LABEL="WD16_00AAJB.02" 
UUID="257fbb4c-4526-4da0-a287-4f6b93c3ca87" TYPE="ext2" 

/dev/sdb3: LABEL="WD16_00AAJB.03" 
UUID="56b87482-73bf-4343-af80-4ddd98c1e377" TYPE="ext2" 

/dev/sdb5: LABEL="WD16_00AAJB.05" 
UUID="cd0db4e9-1ef7-49fb-afa9-415cc83da95c" TYPE="ext2" 

/dev/sdb6: LABEL="WD16_00AAJB.06" 
UUID="d8701e3c-8357-4069-9e96-66ee307d69aa" TYPE="ext2" 

/dev/sdb7: LABEL="WD16_00AAJB.07" 
UUID="89f34b01-5d68-4bb6-927f-ee5b6b7c0a46" TYPE="ext2" 

/dev/hda1: LABEL="6Y080P0.01" 
UUID="1205def1-2141-4b3a-97d0-0b94ca1c4ff2" TYPE="ext2" 

/dev/hda5: LABEL="6Y080P0.05" 
UUID="dc767bc6-ebe4-4dfb-a8f1-739709598dc7" TYPE="ext2"
/dev/hda6: LABEL="6Y080P0.06" 
UUID="a7cfe5f2-b136-4a73-ac8a-f3e2121102c8" TYPE="ext2"
/dev/hda7: LABEL="6Y080P0.07" 
UUID="45ee8af8-c443-42d4-ae59-6f68e33932e8" TYPE="ext2"

/dev/hda8: LABEL="win_D" UUID="4131-BA32" TYPE="vfat"
/dev/hda9: LABEL="6Y080P0.09" 
UUID="5a09faf0-6f8e-4c72-a23b-46fe963754ef" TYPE="swap"
/dev/hda10: LABEL="6Y080P0.10" 
UUID="66c1d026-1e4c-4392-8aa0-e0d9f2cb4277" TYPE="ext2"
/dev/hdc1: LABEL="ST380011A.01" 
UUID="1ab511e2-8e17-460e-91e2-a46d85c55654" TYPE="ext2"
/dev/hdc2: LABEL="ST380011A.02" 
UUID="4c899a3a-4a3c-4910-aa35-a86a24e9c036" TYPE="ext2"
/dev/hdc3: LABEL="ST380011A.03" 
UUID="4c899a3a-4a3c-4910-aa35-a86a24e9c036" TYPE="ext2"
/dev/hdc5: LABEL="ST380011A.05" 
UUID="3ff336b4-c16e-43c4-868a-b50dd22ebe59" TYPE="ext2"
/dev/hdc6: LABEL="ST380011A.06" 
UUID="1d4e5f26-36a2-49d2-840d-83206ddedb44" TYPE="ext2"
/dev/hdc7: LABEL="ST380011A.07" 
UUID="5bf6de45-0c3a-453c-9faf-34905b1cc654" TYPE="ext2"
/dev/sda2: LABEL="wd80_0jd-60.02" 
UUID="ca8ce431-52ae-4368-8e55-a93085d39d09" TYPE="ext2"
/dev/sda3: LABEL="wd80_0jd-60.03" 
UUID="276a49d4-e31c-4b5e-aecc-e25558dd6b2c" TYPE="ext2"
/dev/sdb8: LABEL="WD16_00AAJB.08" 
UUID="4fbe9d8e-2efb-4ef8-8189-a9fb494b347d" TYPE="ext2"



--
To UNS

Re: scsi/firewire kernel oops, any point in reporting a bug ?

[Sven Joachim]

On 2010-07-15 03:35 +0200, bri...@aracnet.com wrote:

> Looks like the latest kernel is -5, is that correct ?

Yes.

Sven


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d3upqudu@turtle.gmx.de

Re: scsi/firewire kernel oops, any point in reporting a bug ?

[briand]

On Wed, 14 Jul 2010 09:09:10 +0200
Sven Joachim  wrote:

> On 2010-07-14 04:31 +0200, bri...@aracnet.com wrote:
> 
> > The question is , submit to Debian or to LKML ?
> 
> Report a bug in Debian, they will likely instruct how to report
> upstream.  But first of all, boot a newer kernel because your current
> one…
> 
> > [24128.816259] Pid: 716, comm: scsi_eh_10 Tainted: P
> > 2.6.32-3-amd64 #1  
> 
> …is more than four months old.  It is quite possible that the problem
> has already been solved.
> 

Looks like the latest kernel is -5, is that correct ?

Brian


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100714183551.52e85...@windy.deldotd.com

Re: scsi/firewire kernel oops, any point in reporting a bug ?

[Sven Joachim]

On 2010-07-14 04:31 +0200, bri...@aracnet.com wrote:

> The question is , submit to Debian or to LKML ?

Report a bug in Debian, they will likely instruct how to report
upstream.  But first of all, boot a newer kernel because your current
one…

> [24128.816259] Pid: 716, comm: scsi_eh_10 Tainted: P   2.6.32-3-amd64 
> #1  

…is more than four months old.  It is quite possible that the problem
has already been solved.

Sven


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mxtuleuh@turtle.gmx.de

scsi/firewire kernel oops, any point in reporting a bug ?

[briand]

Hi All,

I've attached the output of dmesg at the end of the e-mail.

As usual  everything was perfectly stable before I made the mistake of
doing dist-upgrade.  I've really got to quit doing that unless I
_really_ need to.

So I can't see that anyone is going to be able to use the information
to do anything, but I thought I'd ask.  If there's a chance then I'll
go ahead and submit a bug report and do what I can to help figure out
the problem.

I think it has something to do with firewire as I'm getting lots of
messages of all sorts of things being broken, and yet firewire seems to
be working fine.

The question is , submit to Debian or to LKML ?


Thanks

Brian

[24128.816103] IP: [] sbp2_scsi_abort+0x19/0x7b 
[firewire_sbp2]
[24128.816121] PGD 1160b3067 PUD 11e490067 PMD 0 
[24128.816129] Oops:  [#1] SMP 
[24128.816135] last sysfs file: /sys/devices/pci:00/:00:0e.0/class
[24128.816141] CPU 0 
[24128.816145] Modules linked in: ip6table_filter ip6_tables iptable_filter 
ip_tables x_tables powernow_k8 cpufreq_stats cpufreq_powersave 
cpufreq_conservative cpufreq_userspace ppdev lp vboxnetadp vboxnetflt vboxdrv 
kvm_amd kvm fuse nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc 
loop dm_mod cp210x usblp usbhid hid usbserial snd_hda_codec_realtek ohci_hcd sg 
firewire_sbp2 ide_cd_mod cdrom snd_hda_intel snd_hda_codec snd_hwdep snd_pcm 
snd_seq snd_timer snd_seq_device snd firewire_ohci nvidia(P) ehci_hcd soundcore 
edac_core i2c_nforce2 usbcore firewire_core ahci forcedeth snd_page_alloc 
k8temp amd74xx i2c_core edac_mce_amd evdev nls_base crc_itu_t pata_jmicron 
parport_pc processor parport pcspkr button ext3 jbd mbcache sd_mod crc_t10dif 
thermal fan thermal_sys ata_generic ide_pci_generic ide_core sata_nv libata 
scsi_mod
[24128.816259] Pid: 716, comm: scsi_eh_10 Tainted: P   2.6.32-3-amd64 
#1  
[24128.816264] RIP: 0010:[]  [] 
sbp2_scsi_abort+0x19/0x7b [firewire_sbp2]
[24128.816277] RSP: 0018:88011d423d30  EFLAGS: 00010286
[24128.816282] RAX:  RBX: 88011e799c00 RCX: 88011dabece8
[24128.816288] RDX: 88011d423d70 RSI: 2002 RDI: a00b0ec1
[24128.816293] RBP: 8800dfabc500 R08: 88011d422000 R09: 880005a155c0
[24128.816298] R10: 8800bb670700 R11: 0246 R12: 
[24128.816303] R13: 0286 R14: 09c4 R15: 
[24128.816310] FS:  7f7c40cb9720() GS:880005a0() 
knlGS:f4db1710
[24128.816316] CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
[24128.816321] CR2: 0010 CR3: 00011e1ef000 CR4: 06f0
[24128.816326] DR0:  DR1:  DR2: 
[24128.816332] DR3:  DR6: 0ff0 DR7: 0400
[24128.816338] Process scsi_eh_10 (pid: 716, threadinfo 88011d422000, task 
88011dabe9f0)
[24128.816342] Stack:
[24128.816346]  880119ac5000 8800dfabc500  
0286
[24128.816353] <0> 880119ac5000 a0003e94  
88020002
[24128.816361] <0> 88011d423d70 88011d423d70 00020002 
0006
[24128.816371] Call Trace:
[24128.816390]  [] ? scsi_send_eh_cmnd+0x1b7/0x29e [scsi_mod]
[24128.816401]  [] ? sbp2_cancel_orbs+0xbb/0xe7 
[firewire_sbp2]
[24128.816417]  [] ? scsi_eh_tur+0x28/0x78 [scsi_mod]
[24128.816433]  [] ? scsi_error_handler+0x328/0x5b5 [scsi_mod]
[24128.816449]  [] ? scsi_error_handler+0x0/0x5b5 [scsi_mod]
[24128.816460]  [] ? kthread+0x79/0x81
[24128.816469]  [] ? child_rip+0xa/0x20
[24128.816476]  [] ? kthread+0x0/0x81
[24128.816482]  [] ? child_rip+0x0/0x20
[24128.816486] Code: 02 74 09 c6 83 93 00 00 00 24 31 d2 59 5b 89 d0 5d c3 53 
48 83 ec 20 48 8b 07 48 c7 c7 c1 0e 0b a0 48 8b 98 88 00 00 00 48 8b 03 <48> 8b 
70 10 31 c0 e8 13 d6 23 e1 48 8b 03 48 8b 40 08 48 8b 30 
[24128.816543] RIP  [] sbp2_scsi_abort+0x19/0x7b 
[firewire_sbp2]
[24128.816553]  RSP 
[24128.816557] CR2: 0010
[24128.816562] ---[ end trace f299684bf0dbe66c ]---


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100713193149.04a36...@windy.deldotd.com

Re: SCSI tape library & ISCSI

[Stan Hoeppner]

Mirco Piccin put forth on 4/9/2010 6:48 PM:
> Hi, thanks for replies.
> 
>>>> it's possible to manage a SCSI tape library (IBM 3581) with ISCSI?
>>>> I need to use that library attached to a server into another server...
>>>
>>> well, the aim is to share the tape library across the network..
>>> Is there a way (iscsi or other) to do the job?
> 
>> What you need is a SCSI to iSCSI bridge.
> 
>> All you need is an iSCSI bridge such as one of these ATTO units:
>>
>>
> http://www.attotech.com/products/product.php?cat=5&scat=8&sku=IPBR-2600-DR0
>>
> http://www.attotech.com/products/product.php?cat=5&scat=8&sku=IPBR-1550-DR0
> 
> Atto device it's not a really cheap solution :-)

Neither was that IBM 3581 tape library.

> Since it's a temporary  need, I'll try to find a workaround...

You should be able to do it with one of the iSCSI targets and a kernel 2.6.x
Linux box containing an ethernet port and a SCSI connector/interface
compatible with your library.

Try looking thoroughly here:
http://sourceforge.net/apps/mediawiki/iscsitarget/index.php?title=FrequentlyAskedQuestions

and here:
http://scst.sourceforge.net/

SCST is probably what you'll want.  It apparently allows direct SCSI<->iSCSI
device pass through, which sounds like what you want/need.

-- 
Stan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bbfdaba.20...@hardwarefreak.com

Re: SCSI tape library & ISCSI

[Mirco Piccin]

Hi, thanks for replies.

>>> it's possible to manage a SCSI tape library (IBM 3581) with ISCSI?
>>> I need to use that library attached to a server into another server...
>>
>> well, the aim is to share the tape library across the network..
>> Is there a way (iscsi or other) to do the job?

> What you need is a SCSI to iSCSI bridge.

> All you need is an iSCSI bridge such as one of these ATTO units:
>
>
http://www.attotech.com/products/product.php?cat=5&scat=8&sku=IPBR-2600-DR0
>
http://www.attotech.com/products/product.php?cat=5&scat=8&sku=IPBR-1550-DR0

Atto device it's not a really cheap solution :-)
Since it's a temporary  need, I'll try to find a workaround...

Regards
M

Re: SCSI tape library & ISCSI

[Stan Hoeppner]

Mirco Piccin put forth on 4/9/2010 9:39 AM:
> Hi,
> 
>> it's possible to manage a SCSI tape library (IBM 3581) with ISCSI?
>> I need to use that library attached to a server into another server...
> 
> well, the aim is to share the tape library across the network..
> Is there a way (iscsi or other) to do the job?

All you need is an iSCSI bridge such as one of these ATTO units:

http://www.attotech.com/products/product.php?cat=5&scat=8&sku=IPBR-2600-DR0
http://www.attotech.com/products/product.php?cat=5&scat=8&sku=IPBR-1550-DR0

They'll make that SCSI tape library appear on the iSCSI network as any
normal iSCSI device.

The 8581 doesn't allow multiple concurrent host access as it was designed in
the late 1990s strictly as a single host direct attach tape libraby.  Thus
you'll need to make sure only one host is accessing the tape library at a
time over iSCSI.  Attempting concurrent access will cause problems and data
loss.

CAVEAT:

Is your IBM 3581 a model L1x or H1x?  H1x uses a high voltage differential
SCSI interface.  It is NOT compatible with the ATTO bridges above which are
both U320 LVD SCSI devices.  LVD stands for Low Voltage Differential.  If
you have the 3581 H1x you will need an iSCSI bridge with a high voltage
differential SCSI port such as this:

http://www.testequipmentconnection.com/products/28976

If you plug an HVD SCSI device into an LVD only port or vice versa, the LVD
device will be permanently damaged and ruined as a result.  "High Voltage"
means exactly that.  Never never plug HVD SCSI into LVD SCSI.

Hope this information helps you.  Good luck.

-- 
Stan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bbfaa61.10...@hardwarefreak.com

Re: SCSI tape library & ISCSI

[Ryan Manikowski]

On 4/9/2010 10:39 AM, Mirco Piccin wrote:
> Hi,
>
> > it's possible to manage a SCSI tape library (IBM 3581) with ISCSI?
> > I need to use that library attached to a server into another server...
>
> well, the aim is to share the tape library across the network..
> Is there a way (iscsi or other) to do the job?
>
> Regards
> M

What you need is a SCSI to iSCSI bridge.

http://www.attostore.com/iscsibridges.html

I do not know of any software that can do this for you.


-- 
 Ryan Manikowski


]] Devision Media Services LLC [[
 www.devision.us
 r...@devision.us | 716.771.2282


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bbf4a3b.2030...@devision.us

Re: SCSI tape library & ISCSI

[Mirco Piccin]

Hi,

> it's possible to manage a SCSI tape library (IBM 3581) with ISCSI?
> I need to use that library attached to a server into another server...

well, the aim is to share the tape library across the network..
Is there a way (iscsi or other) to do the job?

Regards
M

SCSI tape library & ISCSI

[Mirco Piccin]

Hi all,
it's possible to manage a SCSI tape library (IBM 3581) with ISCSI?
I need to use that library attached to a server into another server...

Thanks
Regards
M
**

[SOLVED] SCSI module eata no longer loading automatically from initrd on Sid on i386

[Stephen Powell]

On Wed, 24 Mar 2010 20:23:28 -0400 (EDT), Arthur Marsh wrote:
> Stephen Powell wrote, on 25/03/10 02:47:
>> In the case of eata, the best way to handle the situation is to
>> create an external alias.
>> 
>> What I would do is to create a file called /etc/modprobe.d/local.  In it
>> I would put the following statement:
>> 
>>alias pci:v1044dA400* eata
>> 
>> Then, remove the "eata" entry from /etc/initramfs-tools/modules.  
>> Also make sure that eata is not listed in /etc/modules.  Then,
>> run update-initramfs again.  Check to make sure that the eata module is
>> still included in your initial RAM filesystem.  Re-run lilo, if you're
>> using lilo, then shutdown and reboot.  If I have the syntax right for
>> the alias command above, the hotplug system should load the eata module
>> at the proper time for SCSI adapter device drivers to be loaded, but
>> only if the card is actually found in the system.  If you were to
>> shutdown, remove the board, and boot again, the eata driver would not
>> be loaded, since the board was not found.  In this sense, it is
>> automatic.  (But only after you define the external alias.)
> 
> Yes, this worked thanks.
>
>> If you want to file a bug report that the eata driver should define
>> an internal alias for every board that it supports, you can give it
>> a try.  But I'm not holding my breath.  Good luck.  ;-)
> 
> I'll post something to linux-scsi then (-:.
>
> Regards and thanks for all the help and explanations,
>
> Arthur.

You're welcome.  I'm glad you got it working, and I'm glad I was able
to be of some service.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1045329874.21506871269486070969.javamail.r...@md01.wow.synacor.com

Re: SCSI module eata no longer loading automatically from initrd on Sid on i386

[Arthur Marsh]

Stephen Powell wrote, on 25/03/10 02:47:

On Wed, 24 Mar 2010 07:05:13 -0400 (EDT), Arthur Marsh wrote:
Why shouldn't the eata driver be loaded once the PCI bus has been 
scanned and a device that the eata driver knows about [1044:a400] in 
this case is detected?


00:08.0 SCSI storage controller [0100]: Adaptec (formerly DPT) 
SmartCache/Raid I

-IV Controller [1044:a400] (rev 02)
 Flags: bus master, medium devsel, latency 160, IRQ 11
 BIST result: 00
 I/O ports at d400 [size=32]
 Expansion ROM at ee00 [disabled] [size=32K]


Because the hotplug system doesn't know that eata is the driver for this
board.  Once the eata driver gets loaded, it can detect that the board
supports the EATA/DMA protocol, and therefore it grabs the board.
But the driver has to get loaded first.

...

debian:~# modinfo eata
filename:   /lib/modules/2.6.26-2-686/kernel/drivers/scsi/eata.ko
description:    EATA/DMA SCSI Driver
license:GPL
author: Dario Ballabio
depends:scsi_mod
vermagic:   2.6.26-2-686 SMP mod_unload modversions 686
parm:   eata: equivalent to the "eata=..." kernel boot option.
  Example: modprobe eata "eata=0x7410,0x230,lc:y,tm:0,mq:4,ep:n" (string)

--

Do you see the difference?  There are no "alias" entries for this module.
For whatever reason, the author/maintainer of the eata module elected
not to define internal aliases for each board that the driver supports.
I'm guessing that this is because there are so many boards that the driver
supports that maintaining the list would be a never-ending job.  Also,
some of the boards may be better supported by a more hardware-specific driver,
and if the eata module listed the board then the hotplug system would load
both drivers: the specific one for that board and eata.  And the two
drivers would interfere with each other.


I actually don't think any of those cases apply. Although there were 
several models of SCSI adaptors from DPT, they are no longer made and 
only the eata driver provided support for the DPT SCSI adaptors.


...

The mwave driver was written before Linux had a
hotplug system, and IBM didn't bother to go back and add the alias
retroactively.


This may have been the case. I have not found anyone using the eata 
driver recently.




In the case of eata, the best way to handle the situation is to
create an external alias.

What I would do is to create a file called /etc/modprobe.d/local.  In it
I would put the following statement:

   alias pci:v1044dA400* eata

Then, remove the "eata" entry from /etc/initramfs-tools/modules.  
Also make sure that eata is not listed in /etc/modules.  Then,

run update-initramfs again.  Check to make sure that the eata module is
still included in your initial RAM filesystem.  Re-run lilo, if you're
using lilo, then shutdown and reboot.  If I have the syntax right for
the alias command above, the hotplug system should load the eata module
at the proper time for SCSI adapter device drivers to be loaded, but
only if the card is actually found in the system.  If you were to
shutdown, remove the board, and boot again, the eata driver would not
be loaded, since the board was not found.  In this sense, it is
automatic.  (But only after you define the external alias.)


Yes, this worked thanks.



I'm not sure if the "A" in the device id needs to be upper case or
lower case.  Based on the vendor id for the 3w-9xxx driver, which
uses an upper-case "C", I assumed upper case.  You might have to
experiment a little to get a correct match.

If you want to file a bug report that the eata driver should define
an internal alias for every board that it supports, you can give it
a try.  But I'm not holding my breath.  Good luck.  ;-)



I'll post something to linux-scsi then (-:.

Regards and thanks for all the help and explanations,

Arthur.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: 
http://lists.debian.org/51nq77-i24@ppp121-45-136-118.lns11.adl6.internode.on.net

Re: SCSI module eata no longer loading automatically from initrd on Sid on i386

[Stephen Powell]

On Wed, 24 Mar 2010 07:05:13 -0400 (EDT), Arthur Marsh wrote:
> Why shouldn't the eata driver be loaded once the PCI bus has been 
> scanned and a device that the eata driver knows about [1044:a400] in 
> this case is detected?
> 
> 00:08.0 SCSI storage controller [0100]: Adaptec (formerly DPT) 
> SmartCache/Raid I
> -IV Controller [1044:a400] (rev 02)
>  Flags: bus master, medium devsel, latency 160, IRQ 11
>  BIST result: 00
>  I/O ports at d400 [size=32]
>  Expansion ROM at ee00 [disabled] [size=32K]

Because the hotplug system doesn't know that eata is the driver for this
board.  Once the eata driver gets loaded, it can detect that the board
supports the EATA/DMA protocol, and therefore it grabs the board.
But the driver has to get loaded first.  And the driver will only be
loaded automatically by the hotplug system if a module alias (internal
or external) matches the device identification of the card.  For
comparison purposes, let's look at the 3w-9xxx driver.  This is from
a Lenny system on the i386 architecture:

--

debian:~# modinfo 3w-9xxx
filename:   /lib/modules/2.6.26-2-686/kernel/drivers/scsi/3w-9xxx.ko
version:2.26.02.010
license:GPL
description:3ware 9000 Storage Controller Linux Driver
author: AMCC
srcversion: 81BF6C7871BF808D126874D
alias:  pci:v13C1d1005sv*sd*bc*sc*i*
alias:  pci:v13C1d1004sv*sd*bc*sc*i*
alias:  pci:v13C1d1003sv*sd*bc*sc*i*
alias:  pci:v13C1d1002sv*sd*bc*sc*i*
depends:scsi_mod
vermagic:   2.6.26-2-686 SMP mod_unload modversions 686
debian:~#

--

Do you see those four "alias" lines above?  These are four internal aliases
defined for the module.  They represent four different PCI device
identifications: 13c1:1005, 13c1:1004, 13c1:1003, and 13c1:1002.  If the
hotplug system finds any of these PCI devices in the system, it will
load the 3w-9xxx module, unless a

   blacklist 3w-9xxx

statement is found in a file in the /etc/modprobe.d directory.  By contrast,
look at the output of the "modinfo" command for the eata module:

--

debian:~# modinfo eata
filename:   /lib/modules/2.6.26-2-686/kernel/drivers/scsi/eata.ko
description:EATA/DMA SCSI Driver
license:GPL
author: Dario Ballabio
depends:scsi_mod
vermagic:   2.6.26-2-686 SMP mod_unload modversions 686
parm:   eata: equivalent to the "eata=..." kernel boot option.
  Example: modprobe eata "eata=0x7410,0x230,lc:y,tm:0,mq:4,ep:n" (string)

--

Do you see the difference?  There are no "alias" entries for this module.
For whatever reason, the author/maintainer of the eata module elected
not to define internal aliases for each board that the driver supports.
I'm guessing that this is because there are so many boards that the driver
supports that maintaining the list would be a never-ending job.  Also,
some of the boards may be better supported by a more hardware-specific driver,
and if the eata module listed the board then the hotplug system would load
both drivers: the specific one for that board and eata.  And the two
drivers would interfere with each other.

I have that problem on my IBM
ThinkPad 600.  By default, the hotplug system wants to load three different
sound drivers: snd-cs4232, snd-cs4236, and snd-wavefront, because all three
of them have an alias called "pnp:dCSC*" which matches the ISA plug-and-
play device id of my CS4237B sound chip.  I only want one of them: snd-cs4236.
I have to manually blacklist snd-cs4232 and snd-wavefront to keep the
hotplug system from loading them.  On the other hand, the mwave module,
which is the correct driver for the ISA plug-and-play device pnp:dIBM3760,
has no internal aliases defined.  I have to define an external alias for
it to get it to load.  The mwave driver was written before Linux had a
hotplug system, and IBM didn't bother to go back and add the alias
retroactively.

In the case of eata, the best way to handle the situation is to
create an external alias.

What I would do is to create a file called /etc/modprobe.d/local.  In it
I would put the following statement:

   alias pci:v1044dA400* eata

Then, remove the "eata" entry from /etc/initramfs-tools/modules.  
Also make sure that eata is not listed in /etc/modules.  Then,
run update-initramfs again.  Check to make sure that the eata module is
still included in your initial RAM filesystem.  Re-run lilo, if you're
using lilo, then shutdown and reboot.  If I have the syntax right for
the alias command above, the hotplug system should load the eata module
at the proper time for SCSI adapter device drivers to be loaded, but
only if the card is actually found in the system.  If you were to
shutdown, remove the board, and boot again, the eata driver would not
be l

Re: SCSI module eata no longer loading automatically from initrd on Sid on i386

[Arthur Marsh]

Stephen Powell wrote, on 24/03/10 01:29:

On Tue, 23 Mar 2010 04:56:05 -0400 (EDT), Arthur Marsh wrote:

Stephen Powell wrote, on 2010-03-23 00:50:

OK, there are a couple of things to check.  First of all, make sure
you have MODULES=most listed in /etc/initramfs-tools/initramfs.conf.

grep -v \# /etc/initramfs-tools/initramfs.conf|uniq

MODULES=most

BUSYBOX=y

KEYMAP=n

BOOT=local

DEVICE=eth0

NFSROOT=auto



Good.


Also check /etc/initramfs-tools/conf.d/driver-policy, if it exists.



$ ls /etc/initramfs-tools/conf.d/driver-policy
ls: cannot access /etc/initramfs-tools/conf.d/driver-policy: No such
file or directory



Good.


Generally, this file only exists if, during installation, you said
you wanted an initial RAM file system with only what is required
to boot the system.  If this is the case,
/etc/initramfs-tools/conf.d/driver-policy will likely exist and
specify MODULES=dep.  And that overrides what is specified in
/etc/initramfs-tools/initramfs.conf.  Change
/etc/initramfs-tools/conf.d/driver-policy to specify
MODULES=most too.  For now, do *not* list eata in
/etc/initramfs-tools/modules.  Then re-run update-initramfs,
re-run lilo (if lilo is your boot loader), shutdown and
reboot.  Let me know the results.


I ran:

update-initramfs -u -k 2.6.32-3-686

then rebooted with break=mount

cat /proc/modules

showed lots of modules but *not* eata.



What happens if you don't use break=mount?


Same problem, eata fails to load by fsck stage.


Are you using dependency-based booting?


Yes, but eata was loading ok with dependency based booting earlier.
Back then, listing eata in /etc/modules was enough to cause eata to load 
before fsck.


Arthur.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: 
http://lists.debian.org/sqjp77-rh3@ppp121-45-136-118.lns11.adl6.internode.on.net

Re: SCSI module eata no longer loading automatically from initrd on Sid on i386

[Arthur Marsh]

Stephen Powell wrote, on 2010-03-24 01:29:

On Tue, 23 Mar 2010 04:56:05 -0400 (EDT), Arthur Marsh wrote:

Stephen Powell wrote, on 2010-03-23 00:50:

OK, there are a couple of things to check.  First of all, make sure
you have MODULES=most listed in /etc/initramfs-tools/initramfs.conf.

grep -v \# /etc/initramfs-tools/initramfs.conf|uniq

MODULES=most

BUSYBOX=y

KEYMAP=n

BOOT=local

DEVICE=eth0

NFSROOT=auto



Good.


Also check /etc/initramfs-tools/conf.d/driver-policy, if it exists.



$ ls /etc/initramfs-tools/conf.d/driver-policy
ls: cannot access /etc/initramfs-tools/conf.d/driver-policy: No such
file or directory



Good.


Generally, this file only exists if, during installation, you said
you wanted an initial RAM file system with only what is required
to boot the system.  If this is the case,
/etc/initramfs-tools/conf.d/driver-policy will likely exist and
specify MODULES=dep.  And that overrides what is specified in
/etc/initramfs-tools/initramfs.conf.  Change
/etc/initramfs-tools/conf.d/driver-policy to specify
MODULES=most too.  For now, do *not* list eata in
/etc/initramfs-tools/modules.  Then re-run update-initramfs,
re-run lilo (if lilo is your boot loader), shutdown and
reboot.  Let me know the results.


I ran:

update-initramfs -u -k 2.6.32-3-686

then rebooted with break=mount

cat /proc/modules

showed lots of modules but *not* eata.



What happens if you don't use break=mount?
Are you using dependency-based booting?

There are four ways I know of for a kernel module to get loaded during boot:


(1) The modules can be loaded by the kernel because they are referenced,
directly or indirectly, during the boot process.  Whether these modules
need to be in the initial RAM filesystem or not depends on when
during the boot process they are referenced.  If they are first referenced
before the permanent root filesystem is mounted, they need to be in
the initial RAM filesystem.  If the first reference is after that point,
they don't.


(2) You can list them in /etc/initramfs-tools/modules and re-run
update-initramfs.  This technique is used for modules which *must*
be explicitly loaded *before* the permanent root file system is mounted.
These modules must be in the initial RAM filesystem.


(3) The modules can be loaded by the hot-plug system.  These modules are
loaded because an alias of the module matches an identification
sequence of the device.  For example, on my IBM ThinkPad 600, module
snd_cs4236 is loaded because it has an alias, pnp:dCSC, that matches
an identification string for the ISA plug-and-play sound chip CS4237B.
A card's identification string can be listed by utilities such as
lspnp, lspci, lspcmcia, etc.  There are two kinds of module aliases:
internal and external.  Internal aliases can be listed by the modinfo
command.  For example: "modinfo snd_cs4236".  External aliases are
listed in one or more files in the /etc/modprobe.d directory.  The
ACPI "discover" process can also load modules.  This automatic loading
can be defeated by listing a module in a "blacklist" statement.  For
example, on my IBM ThinkPad 600, I define the following two blacklist
statements in a file I call /etc/modprobe.d/local:

   blacklist snd_cs4232

   blacklist snd_wavefront

This tells the hotplug system to ignore the internal aliases of kernel
modules snd_cs4232 and snd_wavefront, which causes them not to be
loaded by the hotplug system, even though they both have an alias of
pnp:dCSC, which also matches my CS4237B sound chip.  snd_cs4236
is the correct driver in my case; I don't need the other two.

This is the preferred method for loading kernel modules that are device
drivers for hardware devices.  Whether they need to be in the initial RAM
filesystem or not depends on when the corresponding devices are detected.
Things like SCSI adapters, IDE controllers, etc. are generally probed for
*before* the permanent root filesystem is mounted, for obvious reasons.
Things which are not likely to be required to mount the permanent root file
system, such as sound chips, may be probed for afterward.  Typically,
at this stage the permanent root file system is mounted read-only, but
has not yet been mounted read-write.

At the moment, I do not have access to a 2.6.32 kernel for the i386,
ia64, or amd64 architectures; but on a 2.6.26 kernel for i386 I issued
"modinfo eata" and it does not report any internal aliases.  So
unless the module has an external alias defined in a file listed in
/etc/modprobe.d that matches an identification string for your SCSI
adapter, I would not expect it to be loaded automatically.  On my IBM
ThinkPad 600, I created an external alias for the Mwave® 3780i Digital
Signal Processor (DSP) chip used by the internal modem 

Re: SCSI module eata no longer loading automatically from initrd on Sid on i386

[Stephen Powell]

On Tue, 23 Mar 2010 04:56:05 -0400 (EDT), Arthur Marsh wrote:
> Stephen Powell wrote, on 2010-03-23 00:50:
>> 
>> OK, there are a couple of things to check.  First of all, make sure
>> you have MODULES=most listed in /etc/initramfs-tools/initramfs.conf.
> 
> grep -v \# /etc/initramfs-tools/initramfs.conf|uniq
> 
> MODULES=most
> 
> BUSYBOX=y
> 
> KEYMAP=n
> 
> BOOT=local
> 
> DEVICE=eth0
> 
> NFSROOT=auto
>

Good.

>> Also check /etc/initramfs-tools/conf.d/driver-policy, if it exists.

> $ ls /etc/initramfs-tools/conf.d/driver-policy
> ls: cannot access /etc/initramfs-tools/conf.d/driver-policy: No such
> file or directory
>

Good.

>> Generally, this file only exists if, during installation, you said
>> you wanted an initial RAM file system with only what is required
>> to boot the system.  If this is the case,
>> /etc/initramfs-tools/conf.d/driver-policy will likely exist and
>> specify MODULES=dep.  And that overrides what is specified in
>> /etc/initramfs-tools/initramfs.conf.  Change
>> /etc/initramfs-tools/conf.d/driver-policy to specify
>> MODULES=most too.  For now, do *not* list eata in
>> /etc/initramfs-tools/modules.  Then re-run update-initramfs,
>> re-run lilo (if lilo is your boot loader), shutdown and
>> reboot.  Let me know the results.
> 
>
> I ran:
> 
> update-initramfs -u -k 2.6.32-3-686
> 
> then rebooted with break=mount
> 
> cat /proc/modules
>
> showed lots of modules but *not* eata.
>

What happens if you don't use break=mount?
Are you using dependency-based booting?

There are four ways I know of for a kernel module to get loaded during boot:


(1) The modules can be loaded by the kernel because they are referenced,
directly or indirectly, during the boot process.  Whether these modules
need to be in the initial RAM filesystem or not depends on when
during the boot process they are referenced.  If they are first referenced
before the permanent root filesystem is mounted, they need to be in
the initial RAM filesystem.  If the first reference is after that point,
they don't.


(2) You can list them in /etc/initramfs-tools/modules and re-run
update-initramfs.  This technique is used for modules which *must*
be explicitly loaded *before* the permanent root file system is mounted.
These modules must be in the initial RAM filesystem.


(3) The modules can be loaded by the hot-plug system.  These modules are
loaded because an alias of the module matches an identification
sequence of the device.  For example, on my IBM ThinkPad 600, module
snd_cs4236 is loaded because it has an alias, pnp:dCSC, that matches
an identification string for the ISA plug-and-play sound chip CS4237B.
A card's identification string can be listed by utilities such as
lspnp, lspci, lspcmcia, etc.  There are two kinds of module aliases:
internal and external.  Internal aliases can be listed by the modinfo
command.  For example: "modinfo snd_cs4236".  External aliases are
listed in one or more files in the /etc/modprobe.d directory.  The
ACPI "discover" process can also load modules.  This automatic loading
can be defeated by listing a module in a "blacklist" statement.  For
example, on my IBM ThinkPad 600, I define the following two blacklist
statements in a file I call /etc/modprobe.d/local:

   blacklist snd_cs4232
   blacklist snd_wavefront

This tells the hotplug system to ignore the internal aliases of kernel
modules snd_cs4232 and snd_wavefront, which causes them not to be
loaded by the hotplug system, even though they both have an alias of
pnp:dCSC, which also matches my CS4237B sound chip.  snd_cs4236
is the correct driver in my case; I don't need the other two.

This is the preferred method for loading kernel modules that are device
drivers for hardware devices.  Whether they need to be in the initial RAM
filesystem or not depends on when the corresponding devices are detected.
Things like SCSI adapters, IDE controllers, etc. are generally probed for
*before* the permanent root filesystem is mounted, for obvious reasons.
Things which are not likely to be required to mount the permanent root file
system, such as sound chips, may be probed for afterward.  Typically,
at this stage the permanent root file system is mounted read-only, but
has not yet been mounted read-write.

At the moment, I do not have access to a 2.6.32 kernel for the i386,
ia64, or amd64 architectures; but on a 2.6.26 kernel for i386 I issued
"modinfo eata" and it does not report any internal aliases.  So
unless the module has an external alias defined in a file listed in
/etc/modprobe.d that matches an identific

Re: SCSI module eata no longer loading automatically from initrd on Sid on i386

[Arthur Marsh]

Stephen Powell wrote, on 2010-03-23 00:50:


OK, there are a couple of things to check.  First of all, make sure
you have MODULES=most listed in /etc/initramfs-tools/initramfs.conf.


grep -v \# /etc/initramfs-tools/initramfs.conf|uniq

MODULES=most

BUSYBOX=y

KEYMAP=n

BOOT=local

DEVICE=eth0

NFSROOT=auto


Also check /etc/initramfs-tools/conf.d/driver-policy, if it exists.


$ ls /etc/initramfs-tools/conf.d/driver-policy
ls: cannot access /etc/initramfs-tools/conf.d/driver-policy: No such
file or directory


Generally, this file only exists if, during installation, you said
you wanted an initial RAM file system with only what is required
to boot the system.  If this is the case,
/etc/initramfs-tools/conf.d/driver-policy will likely exist and
specify MODULES=dep.  And that overrides what is specified in
/etc/initramfs-tools/initramfs.conf.  Change
/etc/initramfs-tools/conf.d/driver-policy to specify
MODULES=most too.  For now, do *not* list eata in
/etc/initramfs-tools/modules.  Then re-run update-initramfs,
re-run lilo (if lilo is your boot loader), shutdown and
reboot.  Let me know the results.



I ran:

update-initramfs -u -k 2.6.32-3-686

then rebooted with break=mount

cat /proc/modules

showed lots of modules but *not* eata.

Arthur.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: 
http://lists.debian.org/nacm77-ei3@ppp121-45-136-118.lns11.adl6.internode.on.net

Re: SCSI module eata no longer loading automatically from initrd on Sid on i386

[Stephen Powell]

On Sun, 21 Mar 2010 07:50:57 -0400 (EDT), Arthur Marsh wrote:
> On Sun, 21 Mar 2010 07:28:24 -0400 (EDT), Stephen Powell wrote:
>> On Sun, 21 Mar 2010 04:25:45 -0400 (EDT), Arthur Marsh wrote:
>>> Hi, I have a DPT 2044W SCSI adaptor in this pc for a non-boot disk ... 
>> So what's the problem?
> 
> The problem was that the eata SCSI module was not loaded from the initrd 
> and therefore fsck and mount of the SCSI disk failed.
> 
> I had a look at:
> 
> http://wiki.debian.org/InitramfsDebug
> 
> and temporarily removed eata from /etc/initramfs-tools/modules, ran:
> 
> update-initramfs -u -k 2.6.32-4-686
> 
> then rebooted into that kernel, specifying break=bottom on the linux 
> command line in GRUB2.
> 
> cat /proc/modules
>
> didn't show eata, but did show all the other modules that one would 
> expect to find at boot-up. Running "modprobe eata" worked, it just 
> should have been loaded automatically.

OK, there are a couple of things to check.  First of all, make sure
you have MODULES=most listed in /etc/initramfs-tools/initramfs.conf.
Also check /etc/initramfs-tools/conf.d/driver-policy, if it exists.
Generally, this file only exists if, during installation, you said
you wanted an initial RAM file system with only what is required
to boot the system.  If this is the case,
/etc/initramfs-tools/conf.d/driver-policy will likely exist and
specify MODULES=dep.  And that overrides what is specified in
/etc/initramfs-tools/initramfs.conf.  Change
/etc/initramfs-tools/conf.d/driver-policy to specify
MODULES=most too.  For now, do *not* list eata in
/etc/initramfs-tools/modules.  Then re-run update-initramfs,
re-run lilo (if lilo is your boot loader), shutdown and
reboot.  Let me know the results.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1486357930.20796661269267623424.javamail.r...@md01.wow.synacor.com

Re: SCSI module eata no longer loading automatically from initrd on Sid on i386

[Arthur Marsh]

Stephen Powell wrote, on 21/03/10 21:58:

On Sun, 21 Mar 2010 04:25:45 -0400 (EDT), Arthur Marsh wrote:
Hi, I have a DPT 2044W SCSI adaptor in this pc for a non-boot disk ... 


Your post is quite long; and after reading it twice, I still don't
understand exactly what your question is or what problem you are
trying to solve.  I would normally expect Linux to load the driver
modules for SCSI adapters *before* the permanent root file system is
mounted, since, in the general case, the root file system might
be on a partition on a SCSI disk addressed through that SCSI
adapter.  Apparently in your case your permanent root file system is
*not* located on a partition on a SCSI disk addressed through
this SCSI adapter, but in the general case this might be true.
Therefore, it makes sense that Linux would normally load this module
early.

So what's the problem?



The problem was that the eata SCSI module was not loaded from the initrd 
and therefore fsck and mount of the SCSI disk failed.


I had a look at:

http://wiki.debian.org/InitramfsDebug

and temporarily removed eata from /etc/initramfs-tools/modules, ran:

update-initramfs -u -k 2.6.32-4-686

then rebooted into that kernel, specifying break=bottom on the linux 
command line in GRUB2.


cat /proc/modules

didn't show eata, but did show all the other modules that one would 
expect to find at boot-up. Running "modprobe eata" worked, it just 
should have been loaded automatically.


Arthur.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: 
http://lists.debian.org/7qdh77-4r4@ppp121-45-136-118.lns11.adl6.internode.on.net

Re: SCSI module eata no longer loading automatically from initrd on Sid on i386

[Stephen Powell]

On Sun, 21 Mar 2010 04:25:45 -0400 (EDT), Arthur Marsh wrote:
> Hi, I have a DPT 2044W SCSI adaptor in this pc for a non-boot disk ... 

Your post is quite long; and after reading it twice, I still don't
understand exactly what your question is or what problem you are
trying to solve.  I would normally expect Linux to load the driver
modules for SCSI adapters *before* the permanent root file system is
mounted, since, in the general case, the root file system might
be on a partition on a SCSI disk addressed through that SCSI
adapter.  Apparently in your case your permanent root file system is
*not* located on a partition on a SCSI disk addressed through
this SCSI adapter, but in the general case this might be true.
Therefore, it makes sense that Linux would normally load this module
early.

So what's the problem?

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1000303993.20583431269170904654.javamail.r...@md01.wow.synacor.com

SCSI module eata no longer loading automatically from initrd on Sid on i386

[Arthur Marsh]

Hi, I have a DPT 2044W SCSI adaptor in this pc for a non-boot disk, and 
previously had it working fine with dependency-based booting with the 
required SCSI module eata listed in /etc/modules, all under Debian Sid 
on i386. Module eata would load about 4 seconds into the boot before the 
"INIT 2.86" message appeared.


I didn't do any kernel rebuild for a few weeks, and during that time the 
following packages were updated, amongst others:


[UPGRADE] module-init-tools 3.12~pre1-1 -> 3.12~pre2-1
[UPGRADE] libgudev-1.0-0 151-2 -> 151-3
[UPGRADE] libudev0 151-2 -> 151-3
[UPGRADE] udev 151-2 -> 151-3

the update-initramfs operations triggered by the upgrades only updated a 
different kernel's initrd from what I normally use.


When I built a new kernel (with async SCSI scanning disabled, and SCSI 
driver eata as a module as usual), module eata failed to load and fsck 
failed on the now not-found SCSI disk.


I reported it:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574416
referencing an earlier bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562561

I was eventually able to get everything working again by adding eata to 
/etc/initramfs-tools/modules and re-running update-initramfs on all kernels.


# ONLY RUN USING "-k all" WITH A KNOWN GOOD
# module-init-tools / initramfs-tools /
# anything else that effects module autoloading combination
# test first on a specific kernel with

update-initramfs -u -k test-kernel-version

# leave one or more known bootable kernel/initrd combination(s)
# to recover from a possibly unbootable kernel

# When test kernel boots fine and modules get loaded alright, update
# all kernels' initrds with:
update-initramfs -u -k all

Attempting to downgrade module-init-tools (only version 3.4-1 was 
available in testing or stable, not the 3.12~pre1-1 I had when the whole 
process last worked) resulted in an unbootable system.




To recover, I used sysrescuecd to boot from a cd then did:

SHELL=/bin/sh:export SHELL
(as I didn't have zsh on my hard disk)

mkdir /mnt/newroot
mount /dev/sda7 /mnt/newroot
# /dev/sda7 was my root filesystem on my IDE hard disk
mount /dev/sda1 /mnt/newroot/boot
# I had a separate root file system on the first
# 1024 cylinders / 32 GiB of the disk to get around
# BIOS limitations of the machine

I also had to set my ethernet card up as per the sysrescuecd instructions:
ifconfig eth0 ...
route add default ...

then:

chroot /mnt/newroot

I could run aptitude to upgrade module-init-tools then run:

update-initramfs -u -k 

I would recommend testing different versions of module-init-tools and 
initramfs-tools on only one kernel (using update-initramfs -u -k 
) rather than as I mistakenly used "-k all". That way 
one can boot to a working kernel without a rescuecd.




Anyway, back to the original problem:

I could get module eata loading at the initrd stage by adding eata to 
/etc/initramfs-tools/modules and running update-initramfs, but wonder 
why module would stop auto-loading at the initrd stage?


As suggested in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562561
I ran:

cd tmp
mkdir init
cd init

gunzip -c /boot/initrd.img-kernel-version | \
   cpio -i -d -H newc --no-absolute-filenames

but was not sure what to look for. MODULES=most was already set (module 
eata and all its dependencies were in the initrd), and the only 
scsi-related commands seemed to be in:


init-premount/udev:

modprobe -q scsi_wait_scan && modprobe -r scsi_wait_scan || true

and in lib/udev/rules.d

How would a SCSI adaptor normally be auto-detected in the early stage of 
the boot process once the initrd has been unpacked?


Where would I look for a change in the behaviour of what was run from 
the initrd?


Arthur.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: 
http://lists.debian.org/dp1h77-p2c@ppp121-45-136-118.lns11.adl6.internode.on.net

Re: need advice on scsi disk failure

[owens]

>
>
>
> Original Message 
>From: longwind2...@gmail.com
>To: debian-user@lists.debian.org
>Subject: Re: need advice on scsi disk failure
>Date: Fri, 21 Aug 2009 14:33:10 -0800
>
>>On Fri, Aug 21, 2009 at 7:34 AM,  wrote:
>>>>
>>> The conventional approach is first to clean the contacts on the
>>> connector and the card (some alcohol on a cotton swab for the
>>> connector and a pencil eraser for the card contacts) and try
>again.
>>> If that doesn't work go to "plan B" (run a complete disk
>diagnostic
>>> regularly-if the problem is the connector then the disk diagnostic
>>> will only fail when the connector isn't inserted fully; if the
>>> problem is NOT the connector then the disk diagnostic should pick
>up
>>> the problem).
>>> L
>>>>>
>>>>>--
>>
>>You are right!
>>I don't have alcohol
>>so I just use my hand to rub the connection between cable and
>connector
>>the new power supply (which always fails to power my scsi disk) can
>power it now
>>
>>The human's hand is the best tool!
>>
>>I still have to buy a new scsi cable (and connector?)
>>
Good stuff!  The eraser merely provides some good friction without
producing particles that might muck-up your computer-obviously your
hand worked.  As for me if your system is stable, don't buy some new
cables or connectors ("if it ain't broke don't fix it")
L
>>
>>-- 
>>To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
>>with a subject of "unsubscribe". Trouble? Contact 
listmas...@lists.debian.org
>>
>>



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: need advice on scsi disk failure

[Long Wind]

On Fri, Aug 21, 2009 at 7:34 AM,  wrote:
>>
> The conventional approach is first to clean the contacts on the
> connector and the card (some alcohol on a cotton swab for the
> connector and a pencil eraser for the card contacts) and try again.
> If that doesn't work go to "plan B" (run a complete disk diagnostic
> regularly-if the problem is the connector then the disk diagnostic
> will only fail when the connector isn't inserted fully; if the
> problem is NOT the connector then the disk diagnostic should pick up
> the problem).
> L
>>>
>>>--

You are right!
I don't have alcohol
so I just use my hand to rub the connection between cable and connector
the new power supply (which always fails to power my scsi disk) can power it now

The human's hand is the best tool!

I still have to buy a new scsi cable (and connector?)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: need advice on scsi disk failure

[Long Wind]

On Fri, Aug 21, 2009 at 11:34 AM,  wrote:
> The conventional approach is first to clean the contacts on the
> connector and the card (some alcohol on a cotton swab for the
> connector and a pencil eraser for the card contacts) and try again.
> If that doesn't work go to "plan B" (run a complete disk diagnostic
> regularly-if the problem is the connector then the disk diagnostic
> will only fail when the connector isn't inserted fully; if the
> problem is NOT the connector then the disk diagnostic should pick up
> the problem).
> L

Thanks!
but I don't have alcohol
"If that doesn't work ", the scsi card doesn't find the disk and can't
run disk diagnostic
I have a new power supply and an old one.
Using the new one, the scsi disk always can't be found
but with the old one, I have more luck


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

RE: need advice on scsi disk failure

[owens]

>
>
>
> Original Message 
>From: longwind2...@gmail.com
>To: debian-user@lists.debian.org
>Subject: RE: need advice on scsi disk failure
>Date: Fri, 21 Aug 2009 08:50:21 -0400
>
>>I bought a scsi 50G disk a few years ago
>>The seller said it had been used on server for a long time
>>The scsi card used to warn that the disk will fail soon during boot
>>Then I change SCSI card firmware, the warning disappear
>>>From 5 days ago, the card often can't find disk during boot
>>It's no surprise because the light on scsi disk isn't on
>>I reconnect the power cable to scsi disk again and again
>>and then with some luck the disk works normally.
>>It seems that the power connection becomes loose
>>but I am afraid the disk is failing
>>My question is "Is that symptoms of scsi disk failure?"
>>
The conventional approach is first to clean the contacts on the
connector and the card (some alcohol on a cotton swab for the
connector and a pencil eraser for the card contacts) and try again. 
If that doesn't work go to "plan B" (run a complete disk diagnostic
regularly-if the problem is the connector then the disk diagnostic
will only fail when the connector isn't inserted fully; if the
problem is NOT the connector then the disk diagnostic should pick up
the problem).
L
>>
>>-- 
>>To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
>>with a subject of "unsubscribe". Trouble? Contact 
listmas...@lists.debian.org
>>
>>



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: need advice on scsi disk failure

[mitch]

On Fri, 21 Aug 2009 09:35:25 -0400
Long Wind  wrote:

> On Fri, Aug 21, 2009 at 8:56 AM, mitch
> wrote:
> >
> > I had the same problem, scsi drives failing to start, shutting down
> > while running.
> >
> > Bad power connector. The pins were not making proper contact at all
> > times.
> >
> > Changed the connectors and the problem stopped.
> >
> 
> Really?
> I always think scsi cable and connector are durable component
> I rarely touch these components
> I will buy new ones
> Thanks!

That's what I found. The pins are metal and heat causes metal to
expand and the scsi drives can get warm and the heat gets transferred
to the pins. 


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: need advice on scsi disk failure

[Long Wind]

On Fri, Aug 21, 2009 at 8:56 AM, mitch wrote:
>
> I had the same problem, scsi drives failing to start, shutting down
> while running.
>
> Bad power connector. The pins were not making proper contact at all
> times.
>
> Changed the connectors and the problem stopped.
>

Really?
I always think scsi cable and connector are durable component
I rarely touch these components
I will buy new ones
Thanks!


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: need advice on scsi disk failure

[mitch]

On Fri, 21 Aug 2009 08:50:21 -0400
Long Wind  wrote:

> It's no surprise because the light on scsi disk isn't on
> I reconnect the power cable to scsi disk again and again
> and then with some luck the disk works normally.
> It seems that the power connection becomes loose

I had the same problem, scsi drives failing to start, shutting down
while running.

Bad power connector. The pins were not making proper contact at all
times.

Changed the connectors and the problem stopped.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

need advice on scsi disk failure

[Long Wind]

I bought a scsi 50G disk a few years ago
The seller said it had been used on server for a long time
The scsi card used to warn that the disk will fail soon during boot
Then I change SCSI card firmware, the warning disappear
>From 5 days ago, the card often can't find disk during boot
It's no surprise because the light on scsi disk isn't on
I reconnect the power cable to scsi disk again and again
and then with some luck the disk works normally.
It seems that the power connection becomes loose
but I am afraid the disk is failing
My question is "Is that symptoms of scsi disk failure?"


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: SCSI Emulation with newer Kernels and Burning CD's

[Martin McCormick]

Bhasker C V writes:
>  The native driver can directly do all the tasks and SCSI emulation
> is not needed anymore.
> 
>  For programs like growisofs, cdrecord in the option dev=
>  instead of giving 0,0,0 etc., you can give /dev/hdc directly.

Thank you. That is great news. I figured it was
something like that but I thought I would ask as I will need to
burn 1 in a day or so.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: SCSI Emulation with newer Kernels and Burning CD's

[Bhasker C V]

Hi,

 The native driver can directly do all the tasks and SCSI emulation
is not needed anymore.

 For programs like growisofs, cdrecord in the option dev=
 instead of giving 0,0,0 etc., you can give /dev/hdc directly.


On Tue, 5 May 2009, Martin McCormick wrote:


I upgraded my kernel from an old 2.6.5 kernel to a newer 2.6.18
kernel and noticed that the boot process ignored the passing of
/dev/hdc to scsi emulation. The drive worked fine after I
mounted it as /dev/cdrom rather than /dev/hcd0. Do I need to do
anything different to such programs as cdrecord?

Martin McCormick


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bhasker C V
Registered linux user #306349



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

SCSI Emulation with newer Kernels and Burning CD's

[Martin McCormick]

I upgraded my kernel from an old 2.6.5 kernel to a newer 2.6.18
kernel and noticed that the boot process ignored the passing of
/dev/hdc to scsi emulation. The drive worked fine after I
mounted it as /dev/cdrom rather than /dev/hcd0. Do I need to do
anything different to such programs as cdrecord?

Martin McCormick


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: ensuring SCSI drive is mounted correctly whether or not a USB drive is plugged in at boot-up time

[Boyd Stephen Smith Jr.]

On Tuesday 2009 January 20 05:39:37 Arthur Marsh wrote:
>Ron Johnson wrote, on 20/01/09 06:08:
>> On 01/19/2009 01:30 PM, Boyd Stephen Smith Jr. wrote:
>>> On Monday 2009 January 19 13:15:28 Arthur Marsh wrote:
>>>> I have a machine that boots from and IDE drive then finds an internal
>>>> SCSI drive after any USB drives are found.
>>>>
>>>> The SCSI disk gets fsck'd and mounted fine if there is no USB drive in
>>>> the machine, but the mount -a process at start-up mounts the USB drive
>>>> in place of one of the partitions of the SCSI disk when the USB drive is
>>>> present.
>>>
>>> Don't use device names that are dynamically assigned based on
>>> discovery order (e.g. /dev/sdxN).
>>>
>>> Use /dev/disk/by-{label,uuid,id,path}, if possible; the stock Debian
>>> udev rules should create appropriate symlinks in these directories.
>>>
>>> Failing that, write your own udev rule that reflects how you would
>>> identify the device based on what the kernel "sees" and what name you
>>> would like assigned to it.
>>
>> Or UUID.
>
>The SCSI disk did *not* have entries in /dev/disk/by-uuid, nor entries
>in /dev/disk/by-label and I didn't want to attempt writing a label to
>the disk.

Best I can tell, these are actually properties of the filesystem.  If the SCSI 
disk does not have a filesystem directly on it, it won't show up there.  
(It's partitions might, or LVs residing on it, aut alia.)
-- 
Boyd Stephen Smith Jr. ,= ,-_-. =. 
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy   `-'(. .)`-' 
http://iguanasuicide.net/  \_/ 


signature.asc
Description: This is a digitally signed message part.

Re: ensuring SCSI drive is mounted correctly whether or not a USB drive is plugged in at boot-up time

[Arthur Marsh]

Ron Johnson wrote, on 20/01/09 06:08:

On 01/19/2009 01:30 PM, Boyd Stephen Smith Jr. wrote:

On Monday 2009 January 19 13:15:28 Arthur Marsh wrote:

I have a machine that boots from and IDE drive then finds an internal
SCSI drive after any USB drives are found.

The SCSI disk gets fsck'd and mounted fine if there is no USB drive in
the machine, but the mount -a process at start-up mounts the USB drive
in place of one of the partitions of the SCSI disk when the USB drive is
present.

I'd like to ensure that the SCSI drive always gets mounted properly at
boot-up time, whether or not a USB drive is plugged in.

Any suggestions?

Running Debian unstable, and wanting this to work with a stock Debian
kernel (ie I don't want to build the SCSI driver into the kernel).


Don't use device names that are dynamically assigned based on 
discovery order (e.g. /dev/sdxN).


Use /dev/disk/by-{label,uuid,id,path}, if possible; the stock Debian 
udev rules should create appropriate symlinks in these directories.


Failing that, write your own udev rule that reflects how you would 
identify the device based on what the kernel "sees" and what name you 
would like assigned to it.


Or UUID.

*Attach* your /etc/fstab (so the text doesn't wrap) so we can see what 
the problems are.




The SCSI disk did *not* have entries in /dev/disk/by-uuid, nor entries 
in /dev/disk/by-label and I didn't want to attempt writing a label to 
the disk.


I ended up using the  /dev/disk/by-id entries for the SCSI disk, and the 
/dev/disk/by-label entry for the USB drive.


Thanks for the suggestions. I know that the lenny installer now mounts 
the disks in a new installation by UUID, but I did not have an example 
at hand to draw upon.


Arthur.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: ensuring SCSI drive is mounted correctly whether or not a USB drive is plugged in at boot-up time

[Ron Johnson]

On 01/19/2009 01:30 PM, Boyd Stephen Smith Jr. wrote:

On Monday 2009 January 19 13:15:28 Arthur Marsh wrote:

I have a machine that boots from and IDE drive then finds an internal
SCSI drive after any USB drives are found.

The SCSI disk gets fsck'd and mounted fine if there is no USB drive in
the machine, but the mount -a process at start-up mounts the USB drive
in place of one of the partitions of the SCSI disk when the USB drive is
present.

I'd like to ensure that the SCSI drive always gets mounted properly at
boot-up time, whether or not a USB drive is plugged in.

Any suggestions?

Running Debian unstable, and wanting this to work with a stock Debian
kernel (ie I don't want to build the SCSI driver into the kernel).


Don't use device names that are dynamically assigned based on discovery order 
(e.g. /dev/sdxN).


Use /dev/disk/by-{label,uuid,id,path}, if possible; the stock Debian udev 
rules should create appropriate symlinks in these directories.


Failing that, write your own udev rule that reflects how you would identify 
the device based on what the kernel "sees" and what name you would like 
assigned to it.


Or UUID.

*Attach* your /etc/fstab (so the text doesn't wrap) so we can see 
what the problems are.


--
Ron Johnson, Jr.
Jefferson LA  USA

"I am not surprised, for we live long and are celebrated poopers."


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: ensuring SCSI drive is mounted correctly whether or not a USB drive is plugged in at boot-up time

[Boyd Stephen Smith Jr.]

On Monday 2009 January 19 13:15:28 Arthur Marsh wrote:
>I have a machine that boots from and IDE drive then finds an internal
>SCSI drive after any USB drives are found.
>
>The SCSI disk gets fsck'd and mounted fine if there is no USB drive in
>the machine, but the mount -a process at start-up mounts the USB drive
>in place of one of the partitions of the SCSI disk when the USB drive is
>present.
>
>I'd like to ensure that the SCSI drive always gets mounted properly at
>boot-up time, whether or not a USB drive is plugged in.
>
>Any suggestions?
>
>Running Debian unstable, and wanting this to work with a stock Debian
>kernel (ie I don't want to build the SCSI driver into the kernel).

Don't use device names that are dynamically assigned based on discovery order 
(e.g. /dev/sdxN).

Use /dev/disk/by-{label,uuid,id,path}, if possible; the stock Debian udev 
rules should create appropriate symlinks in these directories.

Failing that, write your own udev rule that reflects how you would identify 
the device based on what the kernel "sees" and what name you would like 
assigned to it.
-- 
Boyd Stephen Smith Jr. ,= ,-_-. =. 
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy   `-'(. .)`-' 
http://iguanasuicide.net/  \_/ 


signature.asc
Description: This is a digitally signed message part.

ensuring SCSI drive is mounted correctly whether or not a USB drive is plugged in at boot-up time

[Arthur Marsh]

I have a machine that boots from and IDE drive then finds an internal 
SCSI drive after any USB drives are found.


The SCSI disk gets fsck'd and mounted fine if there is no USB drive in 
the machine, but the mount -a process at start-up mounts the USB drive 
in place of one of the partitions of the SCSI disk when the USB drive is 
present.


I'd like to ensure that the SCSI drive always gets mounted properly at 
boot-up time, whether or not a USB drive is plugged in.


Any suggestions?

Running Debian unstable, and wanting this to work with a stock Debian 
kernel (ie I don't want to build the SCSI driver into the kernel).


Arthur.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: parallel to scsi converters question

[Ron Johnson]

On 01/11/09 12:48, Jude DaShiell wrote:
I have a parallel to scsi converter and a jazz drive.  If I hook that up 
to the debian box I have running, how will debian see that drive?  I 
expect I can activate parallel port support but once done what kind of a 
new device should I expect to find?


Probably an sd or sg device.

If the parport driver is loaded and udev is running, I'd just plug 
it in and see what happens.


# tail -f /var/log/syslog

--
Ron Johnson, Jr.
Jefferson LA  USA

"I am not surprised, for we live long and are celebrated poopers."


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

parallel to scsi converters question

[Jude DaShiell]

I have a parallel to scsi converter and a jazz drive.  If I hook that up 
to the debian box I have running, how will debian see that drive?  I 
expect I can activate parallel port support but once done what kind of a 
new device should I expect to find?




--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

SOLVED Re: DPT2044W SCSI adaptor with disk installed but no /dev/sd* devices created

[Arthur Marsh]

Arthur Marsh wrote, on 2008-12-09 00:53:

lee wrote, on 2008-11-29 04:07:


Hm, I've always been using the kernels from kernel.org without
problems.


How do you make .deb's of kernel.org kernels under Debian 
(kernel-package, checkinstall, ???)


Arthur.




To make the DPT SCSI card work, I needed to make sure that module eata 
was loaded. So far, I have been loading eata manually using modprobe.


However, the eata module stopped working between kernel 2.6.22 and 
2.6.23. (The site http://snapshot.debian.net had archived images of the 
kernel I could try).


I then obtained the git archive of the 2.6 linux kernel by installing 
the git package and git archive of the linux kernel from 
http://www.kernel.org, then performing a git-bisect to find the commit 
that caused the eata module to stop working.


By posting a bug report to the linux-scsi mailing list, the person who 
had updated the eata module previously supplied a patch (against the 
current version of eata.c in the linux source) which fixed the problem.


The patch is at 
http://www.kernel.org/pub/linux/kernel/people/tomo/fixes/0001-eata-fix-the-sg-conversion-regression.patch


Regards,

Arthur.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Building kernels the Debian way (was: DPT2044W SCSI adaptor with disk installed but no /dev/sd* devices created)

[lee]

On Mon, Dec 08, 2008 at 10:22:51PM +0100, Sven Joachim wrote:
> 
> > Create new default link to new source code 
> 
> This is absolutely unnecessary and maybe even harmful.  Read the README
> in the Linux kernel tree why you should not do it.

The NVIDIA driver doesn't install when it wants to compile a kernel
module and you don't have the source in the default location.


"
   Do NOT use the /usr/src/linux area! This area has a (usually
   incomplete) set of kernel headers that are used by the library header
   files.  They should match the library, and not get messed up by
   whatever the kernel-du-jour happens to be.
"


Who or what puts header files into /user/src/linux? It didn't exist
before I created it.


-- 
"Don't let them, daddy. Don't let the stars run down."
http://adin.dyndns.org/adin/TheLastQ.htm


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DPT2044W SCSI adaptor with disk installed but no /dev/sd* devices created

[Arthur Marsh]

Arthur Marsh wrote, on 2008-12-08 19:58:

I'm still trying to get to the source of the bug that prevents me from 
using a DPT2044W SCSI card that uses the eata module, and have narrowed 
down the working and non-working Debian kernel images to between 
linux-image-2.6.22-3-686 version 2.6.22-6.lenny1 which works, and 
linux-image-2.6.23-1-686 version 2.6.23-1 which fails.


There appear to be a large number of changes between the two and I am 
unfamiliar with how to generate an intermediate kernel source with 
Debian changes and config to build and test.


Thanks all for the comments on building kernel.org source under Debian.

What I'm seeing is that I could do a git clone of a kernel.org 2.6.24 
tree (once I get adsl2+ up and running and buy an extra hard disk) and 
build intermediate kernels (bisection), but surely there must be a way 
of generating intermediate *Debian* kernels to narrow down the source of 
the problem with running the DPT 2044W SCSI card under later kernels.


Arthur.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Building kernels the Debian way (was: DPT2044W SCSI adaptor with disk installed but no /dev/sd* devices created)

[Jochen Schulz]

Sven Joachim:
> 
>> Create a new config file based on the old one, this will prompt for new
>> configuration settings. Read carefully every question. 
>> root# make oldconfig
> 
> Finally, some good advice.  But before this step, you need to copy your
> old config to linux-2.6.22.1/.config and cd to the kernel directory.

The copy should be unnecessary as long as the current config is
available from /proc/config.gz.

Either way, I suggest to go through the hassle to start with a minimal
configuration and only enable those options you need now (or which you
think you may need later). This has two main benefits: kernel compile
time drops *significantly* and you don't need to mess with initrds.

J.
-- 
I have never been happier than I am now; a fact which depresses me
immensely.
[Agree]   [Disagree]
 


signature.asc
Description: Digital signature

Building kernels the Debian way (was: DPT2044W SCSI adaptor with disk installed but no /dev/sd* devices created)

[Sven Joachim]

I feel the need to correct a few bad ideas here.

On 2008-12-08 21:53 +0100, subscriptions wrote:

> Download the source code and unpack

Note, none but one of the steps below require root privileges if you are
a member of the `src' group or perform them below your home directory
instead of /usr/src.

> root# cd /usr/src
> root# wget
> http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.22.1.tar.bz2
> root# bzip2 -d linux-2.6.22.1.tar.bz2
> root# tar -xvf linux-2.6.22.1.tar

Wasting time. Use "tar xjf linux-2.6.22.1.tar.bz2" instead of the last
two steps.

> Create new default link to new source code 

This is absolutely unnecessary and maybe even harmful.  Read the README
in the Linux kernel tree why you should not do it.

> root# cd /usr/src
> root# rm linux
> root# ln -s linux-2.6.22.1 

Omit these steps.

> Create a new config file based on the old one, this will prompt for new
> configuration settings. Read carefully every question. 
> root# make oldconfig

Finally, some good advice.  But before this step, you need to copy your
old config to linux-2.6.22.1/.config and cd to the kernel directory.

> Compile the kernel into .DEB package 
> root# fakeroot make-kpkg --append-to-version "-newkernel" \
>  --revision "20081208"  --us --uc --initrd kernel_image

Using fakeroot is redundant if you are root, but necessary if you follow
my advice and do this as normal user.

> Then install .deb packages created in parent directory

This is really the only step that requires root privileges.

> and link linux
> link to the new header directory in /usr/src. 

No, do not do that.

Sven


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DPT2044W SCSI adaptor with disk installed but no /dev/sd* devices created

[subscriptions]

On Mon, 2008-12-08 at 15:23 +0100, Arthur Marsh wrote:
> lee wrote, on 2008-11-29 04:07:
> 
> > Hm, I've always been using the kernels from kernel.org without
> > problems.
> 
> How do you make .deb's of kernel.org kernels under Debian
> (kernel-package, checkinstall, ???)
> 
> Arthur.



Download the source code and unpack
root# cd /usr/src
root# wget
http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.22.1.tar.bz2
root# bzip2 -d linux-2.6.22.1.tar.bz2
root# tar -xvf linux-2.6.22.1.tar

Create new default link to new source code 
root# cd /usr/src
root# rm linux
root# ln -s linux-2.6.22.1 linux

Create a new config file based on the old one, this will prompt for new
configuration settings. Read carefully every question. 
root# make oldconfig

Compile the kernel into .DEB package 
root# fakeroot make-kpkg --append-to-version "-newkernel" \
 --revision "20081208"  --us --uc --initrd kernel_image

Then install .deb packages created in parent directory and link linux
link to the new header directory in /usr/src. 

Best,

Rob



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DPT2044W SCSI adaptor with disk installed but no /dev/sd* devices created

[Arthur Marsh]

lee wrote, on 2008-11-29 04:07:


Hm, I've always been using the kernels from kernel.org without
problems.


How do you make .deb's of kernel.org kernels under Debian 
(kernel-package, checkinstall, ???)


Arthur.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DPT2044W SCSI adaptor with disk installed but no /dev/sd* devices created

[Arthur Marsh]

lee wrote, on 29/11/08 04:07:

Hm, I've always been using the kernels from kernel.org without
problems.

You should file a bug report about this problem. Obviously something
has changed that makes the current kernels incompatilbe with the eata
module.


Done and ongoing.

I'm still trying to get to the source of the bug that prevents me from 
using a DPT2044W SCSI card that uses the eata module, and have narrowed 
down the working and non-working Debian kernel images to between 
linux-image-2.6.22-3-686 version 2.6.22-6.lenny1 which works, and 
linux-image-2.6.23-1-686 version 2.6.23-1 which fails.


There appear to be a large number of changes between the two and I am 
unfamiliar with how to generate an intermediate kernel source with 
Debian changes and config to build and test.


I am currently running linux-image-2.6.22-3-686 version 2.6.22-6.lenny1 
and dmesg reports the following when loading eata:


EATA/DMA 2.0x: Copyright (C) 1994-2003 Dario Ballabio.
EATA config options -> tm:1, lc:y, mq:16, rs:y, et:n, ip:y, ep:n, pp:y.
EATA0: 2.0C, PCI 0xe010, IRQ 5, BMST, SG 122, MB 64.
EATA0: wide SCSI support enabled, max_id 16, max_lun 8.
EATA0: SCSI channel 0 enabled, host target ID 7.
scsi0 : EATA/DMA 2.0x rev. 8.10.00
scsi 0:0:6:0: Direct-Access IBM  DCAS-34330W  S65A PQ: 0 ANSI: 2
scsi 0:0:6:0: cmds/lun 16, sorted, simple tags.
sd 0:0:6:0: [sda] 8466688 512-byte hardware sectors (4335 MB)
sd 0:0:6:0: [sda] Write Protect is off
sd 0:0:6:0: [sda] Mode Sense: b3 00 00 08
sd 0:0:6:0: [sda] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA

sd 0:0:6:0: [sda] 8466688 512-byte hardware sectors (4335 MB)
sd 0:0:6:0: [sda] Write Protect is off
sd 0:0:6:0: [sda] Mode Sense: b3 00 00 08
sd 0:0:6:0: [sda] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA

 sda: sda1 sda2 < sda5 >
sd 0:0:6:0: [sda] Attached SCSI disk

When loading eata in a later kernel I get some of the same messages 
followed by a kernel stack trace and later lock-up.


Any help on narrowing down the problem appreciated.

Arthur.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DPT2044W SCSI adaptor with disk installed but no /dev/sd* devices created

[lee]

On Sat, Nov 29, 2008 at 12:53:26AM +1030, Arthur Marsh wrote:
> Arthur Marsh wrote, on 28/11/08 20:33:
>
>>
>> The 2.6.18.dfsg.1-12etch2 kernel allowed me to modprobe eata and I
>> received similar messages to those quoted above.
>>
>> The next newest kernel I can download is 2.6.24-etchnhalf.1-686.
>
> kernel 2.6.24-etchnhalf.1-686 had problems after modprobe eata
>
> Is there any site that has precompiled Debian kernels between  
> 2.6.18.dfsg.1-1etch2 and 2.6.24-etchnhalf.1-686 ?

Hm, I've always been using the kernels from kernel.org without
problems.

You should file a bug report about this problem. Obviously something
has changed that makes the current kernels incompatilbe with the eata
module.


-- 
"Don't let them, daddy. Don't let the stars run down."
http://adin.dyndns.org/adin/TheLastQ.htm


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DPT2044W SCSI adaptor with disk installed but no /dev/sd* devices created

[Arthur Marsh]

Arthur Marsh wrote, on 28/11/08 20:33:



The 2.6.18.dfsg.1-12etch2 kernel allowed me to modprobe eata and I
received similar messages to those quoted above.

The next newest kernel I can download is 2.6.24-etchnhalf.1-686.


kernel 2.6.24-etchnhalf.1-686 had problems after modprobe eata

Is there any site that has precompiled Debian kernels between 
2.6.18.dfsg.1-1etch2 and 2.6.24-etchnhalf.1-686 ?


Arthur.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DPT2044W SCSI adaptor with disk installed but no /dev/sd* devices created

[Arthur Marsh]

Arthur Marsh wrote, on 28/11/08 17:02:

You could try older kernels.


Yes, I'll try 2.6.18 (2.6.18.dfsg.1-12etch2 is the earliest Debian 2.6 
kernel I can get hold of from my current archives)




http://grox.net/doc/linux/howto-OLD-VERSIONS/Module-HOWTO-html/Module-HOWTO-6.html 


http://ubuntuforums.org/showthread.php?t=472253
https://bugs.launchpad.net/ubuntu/+bug/120426
http://www.google.com/search?hl=en&q=modprobe+eata&btnG=Search


The sysrescuecd 0.30 beta that found the SCSI controller and hard disk 
identified its kernel version as:


Linux sysrescuecd 2.6.18.3-fd01 #1 Tue Dec 5 11:20:14 UTC 2006 i686 
Pentium II (Klamath) GenuineIntel GNU/Linux


SCSI-related lines from the dmesg output of the sysrescuecd were:

SCSI subsystem initialized
Loading iSCSI transport class v1.1-646.Loading Adaptec I2O RAID: Version 
2.4 Build 5go

scsi:  Detection failed (no card)
Emulex LightPulse Fibre Channel SCSI driver 8.1.9
Failed initialization of WD-7000 SCSI card!
EATA0: wide SCSI support enabled, max_id 16, max_lun 8.
EATA0: SCSI channel 0 enabled, host target ID 7.
scsi2 : EATA/DMA 2.0x rev. 8.10.00
  Type:   Direct-Access  ANSI SCSI revision: 02
scsi 2:0:6:0: cmds/lun 16, unsorted, no tags.
ipr: IBM Power RAID SCSI Device Driver version: 2.1.3 (March 29, 2006)
SCSI device sda: 8466688 512-byte hdwr sectors (4335 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 8466688 512-byte hdwr sectors (4335 MB)
SCSI device sda: drive cache: write back
sd 2:0:6:0: Attached scsi disk sda
sd 2:0:6:0: Attached scsi generic sg0 type 0

The current eata.c from 2.6.27 source on kernel-archive.buildserver.net 
has:


eata.c: .name = "EATA/DMA 2.0x rev. 8.10.00 "

so it appears that the eata.c file hasn't changed significantly since 
the working eata code built-in to the sysrescuecd kernel.


I'll download the 2.6.18.dfsg.1-12etch2 kernel and try it.


The 2.6.18.dfsg.1-12etch2 kernel allowed me to modprobe eata and I
received similar messages to those quoted above.

The next newest kernel I can download is 2.6.24-etchnhalf.1-686.

Arthur.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DPT2044W SCSI adaptor with disk installed but no /dev/sd* devices created

[Arthur Marsh]

lee wrote, on 2008-11-28 04:19:

I've tried a kernel recompile from linux-source-2.6.27 and experienced  
the same problems.


I get a kernel stack trace that ends in:

note: scsi_scan0 [240] exited with preempt_count 1


Did you compile eata into the kernel or as a module?


compiled into the kernel.




and the machine locks up after the line:

clock source tsc unstable


http://www.google.com/search?hl=en&sa=X&oi=spell&resnum=1&ct=result&cd=1&q=%22clocksource+tsc+unstable%22&spell=1
http://kerneltrap.org/node/8306
http://lkml.indiana.edu/hypermail/linux/kernel/0707.1/0621.html


nothing much there, but thanks for the links.




Any suggestions?


No good ones ... You could put the SCSI controller into another slot
and see what happens then --- I've had some SCSI controllers that
won't work in one slot but in another, and I've seen network cards
working just fine in one board but not in another.

You could try older kernels.


Yes, I'll try 2.6.18 (2.6.18.dfsg.1-12etch2 is the earliest Debian 2.6 
kernel I can get hold of from my current archives)




http://grox.net/doc/linux/howto-OLD-VERSIONS/Module-HOWTO-html/Module-HOWTO-6.html
http://ubuntuforums.org/showthread.php?t=472253
https://bugs.launchpad.net/ubuntu/+bug/120426
http://www.google.com/search?hl=en&q=modprobe+eata&btnG=Search


The sysrescuecd 0.30 beta that found the SCSI controller and hard disk 
identified its kernel version as:


Linux sysrescuecd 2.6.18.3-fd01 #1 Tue Dec 5 11:20:14 UTC 2006 i686 
Pentium II (Klamath) GenuineIntel GNU/Linux


SCSI-related lines from the dmesg output of the sysrescuecd were:

SCSI subsystem initialized
Loading iSCSI transport class v1.1-646.Loading Adaptec I2O RAID: Version 
2.4 Build 5go

scsi:  Detection failed (no card)
Emulex LightPulse Fibre Channel SCSI driver 8.1.9
Failed initialization of WD-7000 SCSI card!
EATA0: wide SCSI support enabled, max_id 16, max_lun 8.
EATA0: SCSI channel 0 enabled, host target ID 7.
scsi2 : EATA/DMA 2.0x rev. 8.10.00
  Type:   Direct-Access  ANSI SCSI revision: 02
scsi 2:0:6:0: cmds/lun 16, unsorted, no tags.
ipr: IBM Power RAID SCSI Device Driver version: 2.1.3 (March 29, 2006)
SCSI device sda: 8466688 512-byte hdwr sectors (4335 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 8466688 512-byte hdwr sectors (4335 MB)
SCSI device sda: drive cache: write back
sd 2:0:6:0: Attached scsi disk sda
sd 2:0:6:0: Attached scsi generic sg0 type 0

The current eata.c from 2.6.27 source on kernel-archive.buildserver.net has:

eata.c: .name = "EATA/DMA 2.0x rev. 8.10.00 "

so it appears that the eata.c file hasn't changed significantly since 
the working eata code built-in to the sysrescuecd kernel.


I'll download the 2.6.18.dfsg.1-12etch2 kernel and try it.

Arthur.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DPT2044W SCSI adaptor with disk installed but no /dev/sd* devices created

[lee]

On Thu, Nov 27, 2008 at 10:08:07PM +1030, Arthur Marsh wrote:

>> The correct module for the DPT SCSI card is eata but when I do:
>>
>> modprobe eata
>>
>> I get a kernel stack trace and a system lock-up )-:.
>>
>> I had no problem accessing the SCSI disk using sysrescuecd  
>> (gentoo-based) which does not use an initrd and has eata built-in.
>>
>> I've reported this as Debian Bug #506835.
>>
>> I may have to download the kernel source and recompile the kernel with  
>> eata built-in rather than a module to get a working Debian-based 
>> solution.
>
> I've tried a kernel recompile from linux-source-2.6.27 and experienced  
> the same problems.
>
> I get a kernel stack trace that ends in:
>
> note: scsi_scan0 [240] exited with preempt_count 1

Did you compile eata into the kernel or as a module?

> and the machine locks up after the line:
>
> clock source tsc unstable

http://www.google.com/search?hl=en&sa=X&oi=spell&resnum=1&ct=result&cd=1&q=%22clocksource+tsc+unstable%22&spell=1
http://kerneltrap.org/node/8306
http://lkml.indiana.edu/hypermail/linux/kernel/0707.1/0621.html

> Any suggestions?

No good ones ... You could put the SCSI controller into another slot
and see what happens then --- I've had some SCSI controllers that
won't work in one slot but in another, and I've seen network cards
working just fine in one board but not in another.

You could try older kernels.

http://grox.net/doc/linux/howto-OLD-VERSIONS/Module-HOWTO-html/Module-HOWTO-6.html
http://ubuntuforums.org/showthread.php?t=472253
https://bugs.launchpad.net/ubuntu/+bug/120426
http://www.google.com/search?hl=en&q=modprobe+eata&btnG=Search

find /usr/src/linux/Documentation/scsi -type f | xargs grep -i eata

less /usr/src/linux/drivers/scsi/eata.c

Try different boot options (/usr/src/linux/drivers/scsi/eata.c):


 * boot optionold module param
 * -----
 * addr,...   io_port=addr,...
 * lc:[y|n]   linked_comm=[1|0]
 * mq:xx  max_queue_depth=xx
 * tm:[0|1|2] tag_mode=[0|1|2]
 * et:[y|n]   ext_tran=[1|0]
 * rs:[y|n]   rev_scan=[1|0]
 * ip:[y|n]   isa_probe=[1|0]
 * ep:[y|n]   eisa_probe=[1|0]
 * pp:[y|n]   pci_probe=[1|0]


Read the comments in eata.c, starting at line 323. There are some
hints in there like:


*  Multiple ISA, EISA and PCI boards can be configured in the same system.
*  It is suggested to put all the EISA boards on the same IRQ level, all
*  the PCI  boards on another IRQ level, while ISA boards cannot share
*  interrupts.


Maybe you can get it to work following these hints.


-- 
"Don't let them, daddy. Don't let the stars run down."
http://adin.dyndns.org/adin/TheLastQ.htm


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DPT2044W SCSI adaptor with disk installed but no /dev/sd* devices created

[Arthur Marsh]

Arthur Marsh wrote, on 2008-11-25 17:22:

lee wrote, on 25/11/08 01:24:

On Mon, Nov 24, 2008 at 04:29:52PM +1030, Arthur Marsh wrote:


Hi, I have a DPT2044W SCSI adaptor identified with lspci -vv as:
which has an IBM SCSI disk attached, which contains MS-Windows95 OSR2.

If I set the BIOS to boot SCSI first, the disk is recognised and boots.

I have an IDE disk with sid installed and using 2.6.27 kernel, have 
the  following scsi messages only in dmesg:


[4.619341] Block layer SCSI generic (bsg) driver version 0.4 
loaded  (major 254)

[   12.129340] SCSI subsystem initialized

No /dev/sd* devices get created.


I guess the real SCSI devices need to be available before the generic
driver can create generic devices from them --- but I don't know for
sure. Generic devices would be /dev/sg*, not /dev/sd*.


lsmod reports only the following scsi related module:

scsi_mod  131388  1 libata


You seem to have support for SATA drives enabled in the kernel
configuration, but you don't need that because no SATA drives are
connected. If there were, you would see them as /dev/sd*.


Does anyone have any sugggestions on how to get Debian GNU/Linux to
create the device files for the SCSI disk and be able to see the
disk in gparted and the like?


It seems like you don't have a module installed for the SCSI
card. Google should tell you which module is needed for this card. If
you can load the module with modprobe, it's already available. If you
don't have the module, you can reconfigure and recompile your kernel
to get it. If you want to boot from SCSI, it can be a good idea to
compile SCSI support as needed into the kernel instead of using
modules.




The correct module for the DPT SCSI card is eata but when I do:

modprobe eata

I get a kernel stack trace and a system lock-up )-:.

I had no problem accessing the SCSI disk using sysrescuecd 
(gentoo-based) which does not use an initrd and has eata built-in.


I've reported this as Debian Bug #506835.

I may have to download the kernel source and recompile the kernel with 
eata built-in rather than a module to get a working Debian-based solution.


I've tried a kernel recompile from linux-source-2.6.27 and experienced 
the same problems.


I get a kernel stack trace that ends in:

note: scsi_scan0 [240] exited with preempt_count 1

and the machine locks up after the line:

clock source tsc unstable

Any suggestions?

Arthur.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DPT2044W SCSI adaptor with disk installed but no /dev/sd* devices created

[Arthur Marsh]

lee wrote, on 25/11/08 01:24:

On Mon, Nov 24, 2008 at 04:29:52PM +1030, Arthur Marsh wrote:


Hi, I have a DPT2044W SCSI adaptor identified with lspci -vv as:
which has an IBM SCSI disk attached, which contains MS-Windows95 OSR2.

If I set the BIOS to boot SCSI first, the disk is recognised and boots.

I have an IDE disk with sid installed and using 2.6.27 kernel, have the  
following scsi messages only in dmesg:


[4.619341] Block layer SCSI generic (bsg) driver version 0.4 loaded  
(major 254)

[   12.129340] SCSI subsystem initialized

No /dev/sd* devices get created.


I guess the real SCSI devices need to be available before the generic
driver can create generic devices from them --- but I don't know for
sure. Generic devices would be /dev/sg*, not /dev/sd*.


lsmod reports only the following scsi related module:

scsi_mod  131388  1 libata


You seem to have support for SATA drives enabled in the kernel
configuration, but you don't need that because no SATA drives are
connected. If there were, you would see them as /dev/sd*.


Does anyone have any sugggestions on how to get Debian GNU/Linux to
create the device files for the SCSI disk and be able to see the
disk in gparted and the like?


It seems like you don't have a module installed for the SCSI
card. Google should tell you which module is needed for this card. If
you can load the module with modprobe, it's already available. If you
don't have the module, you can reconfigure and recompile your kernel
to get it. If you want to boot from SCSI, it can be a good idea to
compile SCSI support as needed into the kernel instead of using
modules.




The correct module for the DPT SCSI card is eata but when I do:

modprobe eata

I get a kernel stack trace and a system lock-up )-:.

I had no problem accessing the SCSI disk using sysrescuecd 
(gentoo-based) which does not use an initrd and has eata built-in.


I've reported this as Debian Bug #506835.

I may have to download the kernel source and recompile the kernel with 
eata built-in rather than a module to get a working Debian-based solution.


Thanks for your suggestions.

Arthur.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DPT2044W SCSI adaptor with disk installed but no /dev/sd* devices created

[lee]

On Mon, Nov 24, 2008 at 04:29:52PM +1030, Arthur Marsh wrote:

> Hi, I have a DPT2044W SCSI adaptor identified with lspci -vv as:
> which has an IBM SCSI disk attached, which contains MS-Windows95 OSR2.
>
> If I set the BIOS to boot SCSI first, the disk is recognised and boots.
>
> I have an IDE disk with sid installed and using 2.6.27 kernel, have the  
> following scsi messages only in dmesg:
>
> [    4.619341] Block layer SCSI generic (bsg) driver version 0.4 loaded  
> (major 254)
> [   12.129340] SCSI subsystem initialized
>
> No /dev/sd* devices get created.

I guess the real SCSI devices need to be available before the generic
driver can create generic devices from them --- but I don't know for
sure. Generic devices would be /dev/sg*, not /dev/sd*.

> lsmod reports only the following scsi related module:
>
> scsi_mod  131388  1 libata

You seem to have support for SATA drives enabled in the kernel
configuration, but you don't need that because no SATA drives are
connected. If there were, you would see them as /dev/sd*.

> Does anyone have any sugggestions on how to get Debian GNU/Linux to
> create the device files for the SCSI disk and be able to see the
> disk in gparted and the like?

It seems like you don't have a module installed for the SCSI
card. Google should tell you which module is needed for this card. If
you can load the module with modprobe, it's already available. If you
don't have the module, you can reconfigure and recompile your kernel
to get it. If you want to boot from SCSI, it can be a good idea to
compile SCSI support as needed into the kernel instead of using
modules.


-- 
http://en.wikipedia.org/wiki/Posting_style


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]