* firewire in 2.4.21-ben2
@ 2003-07-14 19:19 daRonin
2003-07-15 9:30 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 7+ messages in thread
From: daRonin @ 2003-07-14 19:19 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I just upgraded to 2.4.21-ben2 kernel. And I can't mount my firewire
HDDs any longer.
These are the commands I am executing:
modprobe -k ieee1394
modprobe -k ohci1394
modprobe -k sbp2
modprobe -k raw1394
modprobe -k sd_mod
mount /dev/sda2 /mnt/fire
Judging by the logs everything seems to go fine up to inserting sd_mod.
sbp2 module seems to see the device and such.
But after inserting sd_mod absolutely nothing happens. I tried rmmod'ing
the modules and inserting them again, tried to switch the order around,
etc. No luck...
After I reboot back in 2.4.20-ben10 everything works fine...
daRonin
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: firewire in 2.4.21-ben2
2003-07-14 19:19 firewire in 2.4.21-ben2 daRonin
@ 2003-07-15 9:30 ` Benjamin Herrenschmidt
2003-07-17 10:11 ` Calum Selkirk
0 siblings, 1 reply; 7+ messages in thread
From: Benjamin Herrenschmidt @ 2003-07-15 9:30 UTC (permalink / raw)
To: daRonin; +Cc: linuxppc-dev
On Mon, 2003-07-14 at 21:19, daRonin wrote:
> Hi,
>
> I just upgraded to 2.4.21-ben2 kernel. And I can't mount my firewire
> HDDs any longer.
>
> These are the commands I am executing:
>
> modprobe -k ieee1394
> modprobe -k ohci1394
> modprobe -k sbp2
> modprobe -k raw1394
> modprobe -k sd_mod
> mount /dev/sda2 /mnt/fire
>
> Judging by the logs everything seems to go fine up to inserting sd_mod.
> sbp2 module seems to see the device and such.
>
> But after inserting sd_mod absolutely nothing happens. I tried rmmod'ing
> the modules and inserting them again, tried to switch the order around,
> etc. No luck...
>
> After I reboot back in 2.4.20-ben10 everything works fine...
That's a change in the firewire layer, you have to trigger a scsi probe
yourself now. Either using the rescan-scsi-bus.sh script, or the scsiadd
command for example
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: firewire in 2.4.21-ben2
2003-07-15 9:30 ` Benjamin Herrenschmidt
@ 2003-07-17 10:11 ` Calum Selkirk
2003-07-26 14:39 ` Calum Selkirk
0 siblings, 1 reply; 7+ messages in thread
From: Calum Selkirk @ 2003-07-17 10:11 UTC (permalink / raw)
To: linuxppc-dev
* Benjamin Herrenschmidt [benh@kernel.crashing.org] [2003-07-15 11:30 +0200]:
[snip]
> > After I reboot back in 2.4.20-ben10 everything works fine...
>
> That's a change in the firewire layer, you have to trigger a scsi
> probe yourself now. Either using the rescan-scsi-bus.sh script, or the
> scsiadd command for example
just FYI, I have had the kernel oops on one occasion when rescaning the
scsi bus this way (with a 2.4.21-ben2). Sorry, wasn't able to get a
backtrace, though I will attempt to if it happens again.
best regards
cal
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: firewire in 2.4.21-ben2
2003-07-17 10:11 ` Calum Selkirk
@ 2003-07-26 14:39 ` Calum Selkirk
2003-07-27 16:06 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 7+ messages in thread
From: Calum Selkirk @ 2003-07-26 14:39 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 975 bytes --]
* Calum Selkirk [cselkirk@xs4all.nl] [2003-07-17 12:11 +0200]:
> * Benjamin Herrenschmidt [benh@kernel.crashing.org] [2003-07-15 11:30 +0200]:
>
> [snip]
> > > After I reboot back in 2.4.20-ben10 everything works fine...
> >
> > That's a change in the firewire layer, you have to trigger a scsi
> > probe yourself now. Either using the rescan-scsi-bus.sh script, or the
> > scsiadd command for example
>
> just FYI, I have had the kernel oops on one occasion when rescaning the
> scsi bus this way (with a 2.4.21-ben2). Sorry, wasn't able to get a
> backtrace, though I will attempt to if it happens again.
OK .. attatched is a backtrace (hopefully accuratly transcribed) and
snippit from /var/log/messages.
As i said previously I haven't been able to reproduce this, it's only
happened to me on one occassion (the above backtrace is from another
user/machine). Might this be related to the other ieee1394 bug, where
unloading ohci1394 after sleep will oops?
best
cal
[-- Attachment #2: kernel-oops --]
[-- Type: text/plain, Size: 2059 bytes --]
scsi singledevice 0 0 1 0
scsi singledevice 0 0 2 0
scsi singledevice 0 0 3 0
scsi singledevice 0 0 4 0
scsi singledevice 0 0 5 0
scsi singledevice 0 0 6 0
scsi singledevice 0 0 7 0
scsi singledevice 0 0 0 0
blk: queue cf131c14, I/O limit 4095Mb (mask 0xffffffff)
Machine check in kernel mode.
Caused by (from SRR1=41030): Transfer error ack signal
Oops: machine check, sig: 7
NIP: D2025104 XER: 20000000 LR: D20250D0 SP: CB499AE0 REGS: cb499a30 TRAP: 0200 Not tainted
MSR: 00041030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = cb498000[2407] 'rescan-scsi-bus' Last syscall: 4
last math cb498000 last altivec 00000000
GPR00: FFFFFFFF CB499AE0 CB498000 CFDB3BD4 CFDB3D10 CF8B40C0 00000008 D202C000
GPR08: CFDB3D3C 0000001F 00000180 D202C180 00000008 100D6E90 100D0000 00000000
GPR16: 00000000 00000001 00000000 00000001 00009032 CB499EA4 C0230940 CF131C34
GPR24: CF131C14 00000000 00000003 00000001 00000000 CFDB3BD4 CFDB3D44 CFDB3D10
Call backtrace:
D2025214 D2318F04 D202FF90 D20300B0 D20306FC D230266C D230A61C
D2309AC8 D2309B58 D2302968 D230288C D230CA38 D230C7A0 D23035D8
C005F894 C003BA1C C0005D3C 4822282C 0FEF8CCC 0FEF8C50 0FEF9794
0FEFAF34 0FEF5528 10061734 100294F4 10027C98 10027524 10024514
10025374 100247DC 10025320 100247DC 10025320
ieee1394: sbp2: aborting sbp2 command
Inquiry 00 00 00 ff 00
Machine check in kernel mode.
Caused by (from SRR1=41030): Transfer error ack signal
Oops: machine check, sig: 7
NIP: D2025104 XER: 00000000 LR: D20250D0 SP: CB559EC0 REGS: cb559e10 TRAP: 0200 Not tainted
MSR: 00041030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = cb558000[2008] 'scsi_eh_0' Last syscall: -1
last math 00000000 last altivec 00000000
GPR00: FFFFFFFF CB559EC0 CB558000 CFDB3BD4 CFDB3D10 CF8B411C 00000000 D202C000
GPR08: CF8B40C8 0000001E 00000180 D202C180 84224428 1001FFB8 0FFED250 00000000
GPR16: 00000001 00000003 10030000 10030000 00009032 0B53FF40 00000000 CB53FEA8
GPR24: CB558000 D2310000 00000002 00000002 00000000 CFDB3BD4 CFDB3D44 CFDB3D10
Call backtrace:
D2025214 D2318F04 D202FA44 D2030A5C D23079BC D2308674 D2308894
C0008748
[-- Attachment #3: backtrace-rescan-scsi --]
[-- Type: text/plain, Size: 443 bytes --]
100258d0
10024704
100258d0
10024704
100258d0
10024704
10024874
100299f0
10027db8
10027524
10024514
100258d0
10024704
10028ac0
1001660c
100141b4
0fea0d44
00000000
mon>
d23035d8
c005f894
c003ba1c
exception:c00 [cb499f50] ff5641c
0fef8ccc
0fef8c50
0fef9794
0fefaf34
0fef5528
10061734
100294f4
10027c98
10027524
10024514
10025374
100247dc
10025320
100247dc
10025320
100247dc
10025320
100247dc
10026a0c
1002478c
10025374
100247dc
10025320
100247dc
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: firewire in 2.4.21-ben2
2003-07-26 14:39 ` Calum Selkirk
@ 2003-07-27 16:06 ` Benjamin Herrenschmidt
2003-07-27 20:56 ` Calum Selkirk
0 siblings, 1 reply; 7+ messages in thread
From: Benjamin Herrenschmidt @ 2003-07-27 16:06 UTC (permalink / raw)
To: Calum Selkirk; +Cc: linuxppc-dev
On Sat, 2003-07-26 at 10:39, Calum Selkirk wrote:
> * Calum Selkirk [cselkirk@xs4all.nl] [2003-07-17 12:11 +0200]:
>
> > * Benjamin Herrenschmidt [benh@kernel.crashing.org] [2003-07-15 11:30 +0200]:
> >
> > [snip]
> > > > After I reboot back in 2.4.20-ben10 everything works fine...
> > >
> > > That's a change in the firewire layer, you have to trigger a scsi
> > > probe yourself now. Either using the rescan-scsi-bus.sh script, or the
> > > scsiadd command for example
> >
> > just FYI, I have had the kernel oops on one occasion when rescaning the
> > scsi bus this way (with a 2.4.21-ben2). Sorry, wasn't able to get a
> > backtrace, though I will attempt to if it happens again.
>
> OK .. attatched is a backtrace (hopefully accuratly transcribed) and
> snippit from /var/log/messages.
>
> As i said previously I haven't been able to reproduce this, it's only
> happened to me on one occassion (the above backtrace is from another
> user/machine). Might this be related to the other ieee1394 bug, where
> unloading ohci1394 after sleep will oops?
A backtrace with just numbers is useless, you should either provide
insmod -m output or run the oops through ksymoops.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: firewire in 2.4.21-ben2
2003-07-27 16:06 ` Benjamin Herrenschmidt
@ 2003-07-27 20:56 ` Calum Selkirk
0 siblings, 0 replies; 7+ messages in thread
From: Calum Selkirk @ 2003-07-27 20:56 UTC (permalink / raw)
To: linuxppc-dev
* Benjamin Herrenschmidt [benh@kernel.crashing.org] [2003-07-27 12:06 -0400]:
> > OK .. attatched is a backtrace (hopefully accuratly transcribed) and
> > snippit from /var/log/messages.
> >
> > As i said previously I haven't been able to reproduce this, it's only
> > happened to me on one occassion (the above backtrace is from another
> > user/machine). Might this be related to the other ieee1394 bug, where
> > unloading ohci1394 after sleep will oops?
>
> A backtrace with just numbers is useless, you should either provide
> insmod -m output or run the oops through ksymoops.
ok, sorry. As i said this wasn't from my own machine. When it next
appears I'll run it through ksymoops (I wasn't until now aware of the
tool).
best
cal
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: firewire in 2.4.21-ben2
@ 2003-07-15 4:40 Bill Fink
0 siblings, 0 replies; 7+ messages in thread
From: Bill Fink @ 2003-07-15 4:40 UTC (permalink / raw)
To: LinuxPPC Developers; +Cc: daronin, Bill Fink
On Mon, 14 Jul 2003, daRonin wrote:
> I just upgraded to 2.4.21-ben2 kernel. And I can't mount my firewire
> HDDs any longer.
>
> These are the commands I am executing:
>
> modprobe -k ieee1394
> modprobe -k ohci1394
> modprobe -k sbp2
> modprobe -k raw1394
> modprobe -k sd_mod
> mount /dev/sda2 /mnt/fire
>
> Judging by the logs everything seems to go fine up to inserting sd_mod.
> sbp2 module seems to see the device and such.
>
> But after inserting sd_mod absolutely nothing happens. I tried rmmod'ing
> the modules and inserting them again, tried to switch the order around,
> etc. No luck...
>
> After I reboot back in 2.4.20-ben10 everything works fine...
Run rescan-scsi-bus.sh.
-Bill
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2003-07-27 20:56 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-07-14 19:19 firewire in 2.4.21-ben2 daRonin
2003-07-15 9:30 ` Benjamin Herrenschmidt
2003-07-17 10:11 ` Calum Selkirk
2003-07-26 14:39 ` Calum Selkirk
2003-07-27 16:06 ` Benjamin Herrenschmidt
2003-07-27 20:56 ` Calum Selkirk
-- strict thread matches above, loose matches on Subject: below --
2003-07-15 4:40 Bill Fink
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).