Re: cx88 teletext not yet implemented -was- Re: Linux-2.6.13-rc6: aic7xxx testers please..
On Thursday 11 August 2005 11:38, Michael Krufky wrote: >Gene Heskett wrote: >>I can also report that teletext decoding has ceased to work >>here. But I'm not sure what kernel version killed it. Currently >>running 2.6.13-rc6. But my card is cx88 based, a pcHDTV-3000. But >>attempting to switch it on/off doesn't seem to generate any output >>indicating it failed, it just Doesn't Work(TM) > >Gene- > >By teletext, I assume you are referring to closed captions. Are you >sure that closed captions EVER worked for you on a cx88-based card? >AFAIK, this feature has not yet been implemented. I am not at home > now, so I cannot try it, however, IIRC, closed captions is > implemented in bttv, and not yet in cx88. > >This is a v4l issue, not a dvb issue, however, it is NOT an issue. > This is not a regression, because the feature has not yet been > implemented. > >Gene, if I am wrong, (this is possible) then please provide the last >kernel version that had this feature correctly implemented. I don't >think that I am wrong, though. Please investigate this and confirm > that this is an actual regression or not. > >Cheers, Its entirely possible that the last time I saw it work was in fact on a bt878 card, one I junked because the tuner was apparently damaged, needing something like 10,000 u-v to give a useable picture. I assumed (theres that word again) that the CC decoding was seperately handled by inspecting the output video data stream regardless of its source. Mentally to me, that then would have been a tvtime function and not a cx88 function. It makes far more sense to me anyway. Sorry for the false alarm. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
cx88 teletext not yet implemented -was- Re: Linux-2.6.13-rc6: aic7xxx testers please..
Gene Heskett wrote: I can also report that teletext decoding has ceased to work here. But I'm not sure what kernel version killed it. Currently running 2.6.13-rc6. But my card is cx88 based, a pcHDTV-3000. But attempting to switch it on/off doesn't seem to generate any output indicating it failed, it just Doesn't Work(TM) Gene- By teletext, I assume you are referring to closed captions. Are you sure that closed captions EVER worked for you on a cx88-based card? AFAIK, this feature has not yet been implemented. I am not at home now, so I cannot try it, however, IIRC, closed captions is implemented in bttv, and not yet in cx88. This is a v4l issue, not a dvb issue, however, it is NOT an issue. This is not a regression, because the feature has not yet been implemented. Gene, if I am wrong, (this is possible) then please provide the last kernel version that had this feature correctly implemented. I don't think that I am wrong, though. Please investigate this and confirm that this is an actual regression or not. Cheers, -- Michael Krufky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
Hello Michael! On Thu, Aug 11, 2005 at 02:37:20PM +0200, [EMAIL PROTECTED] wrote: > >I got the following OOPS from running "alevtd -F -d -v /dev/vbi0" with > >my Siemens-DVB-C on a Dual-i686-600. I'm able to reproduce this even > >running a 2.6.12-rc6 without the nvidia module tainting the kernel. > > So you're using the analog tuner of the card to watch analog cable tv and > want to decode teletext from the vbi, right? Yes. > Can you tell me the last kernel version that worked for you? Sorry, it never worked before: After accessing /dev/vbi the computer locked up after some time: no keyboard, only hard reset. Might be related to that it is a dual P3-600. I just tried it again yesterday to see if the situation with VBI improved with the updated which went into 2.6.13-rc6 compared to the situation half a year ago. > >kernel BUG at drivers/media/common/saa7146_video.c:741! > > 739 fmt = format_by_fourcc(dev,fh->video_fmt.pixelformat); > 740 /* we need to have a valid format set here */ > 741 BUG_ON(NULL == fmt); > > This sanity check is failing. Apparently the software managed > to select a pixelformat that cannot be translated to a "saa7146 format". > > Puh, I wrote this long ago. ;-) IIRC this should not be possible (ie. the > driver should reject the unknown pixelformat in the configuring stage). alevtd is outputting some debug information, which I'll capture for you. > Did you update the alevt package? Perhaps it's now doing this differently > and it would fail with older kernels as well, which have worked before. alevtd is Debians 3.94-1 > We will probably have to debug this on a very low level. Please feel free to contact my. Turn around might by long, since the PC with DVB is at home without internet access, which I only have at work. BYtE Philipp PS: Wir koennen auch Deutsch reden, nachdem wir die cc:-Liste reduziert haben. -- / / (_)__ __ __ Philipp Hahn / /__/ / _ \/ // /\ \/ / //_/_//_/\_,_/ /_/\_\ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
On Thursday 11 August 2005 08:37, [EMAIL PROTECTED] wrote: >Hello Philipp, > >> I got the following OOPS from running "alevtd -F -d -v /dev/vbi0" >> with my Siemens-DVB-C on a Dual-i686-600. I'm able to reproduce >> this even running a 2.6.12-rc6 without the nvidia module tainting >> the kernel. > >So you're using the analog tuner of the card to watch analog cable > tv and want to decode teletext from the vbi, right? Yes, and I can also report that teletext decoding has ceased to work here. But I'm not sure what kernel version killed it. Currently running 2.6.13-rc6. But my card is cx88 based, a pcHDTV-3000. But attempting to switch it on/off doesn't seem to generate any output indicating it failed, it just Doesn't Work(TM) >Can you tell me the last kernel version that worked for you? > >> ... >> kernel BUG at drivers/media/common/saa7146_video.c:741! > >739 fmt = format_by_fourcc(dev,fh->video_fmt.pixelformat); >740 /* we need to have a valid format set here */ >741 BUG_ON(NULL == fmt); > >This sanity check is failing. Apparently the software managed >to select a pixelformat that cannot be translated to a "saa7146 > format". > >Puh, I wrote this long ago. ;-) IIRC this should not be possible > (ie. the driver should reject the unknown pixelformat in the > configuring stage). > >Did you update the alevt package? Perhaps it's now doing this > differently and it would fail with older kernels as well, which > have worked before. > >We will probably have to debug this on a very low level. > >Regards >Michael. > >- >To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
Hello Philipp, I got the following OOPS from running "alevtd -F -d -v /dev/vbi0" with my Siemens-DVB-C on a Dual-i686-600. I'm able to reproduce this even running a 2.6.12-rc6 without the nvidia module tainting the kernel. So you're using the analog tuner of the card to watch analog cable tv and want to decode teletext from the vbi, right? Can you tell me the last kernel version that worked for you? ... kernel BUG at drivers/media/common/saa7146_video.c:741! 739 fmt = format_by_fourcc(dev,fh->video_fmt.pixelformat); 740 /* we need to have a valid format set here */ 741 BUG_ON(NULL == fmt); This sanity check is failing. Apparently the software managed to select a pixelformat that cannot be translated to a "saa7146 format". Puh, I wrote this long ago. ;-) IIRC this should not be possible (ie. the driver should reject the unknown pixelformat in the configuring stage). Did you update the alevt package? Perhaps it's now doing this differently and it would fail with older kernels as well, which have worked before. We will probably have to debug this on a very low level. Regards Michael. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
On Thu, Aug 11, 2005 Philipp Matthias Hahn wrote: > PS: MAINTAINTER lists http://linuxtv.org/developer/dvb.xml which is > dead. Thanks for reporting. --- Fix DVB URL. Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]> Index: linux-2.6.13-rc6/MAINTAINERS === --- linux-2.6.13-rc6.orig/MAINTAINERS 2005-08-11 11:20:49.0 +0200 +++ linux-2.6.13-rc6/MAINTAINERS2005-08-11 11:23:18.0 +0200 @@ -784,7 +784,7 @@ DVB SUBSYSTEM AND DRIVERS P: LinuxTV.org Project M: [EMAIL PROTECTED] L: linux-dvb@linuxtv.org (subscription required) -W: http://linuxtv.org/developer/dvb.xml +W: http://linuxtv.org/ S: Supported EATA-DMA SCSI DRIVER - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
Hello!
On Sun, Aug 07, 2005 at 11:47:53AM -0700, Linus Torvalds wrote:
> Apart from some reverts and the aic7xxx performance regression fix,
> there's arm and ppc updates, and some PCI resource allocation updates that
> hopefully will reduce the number of machines (especially laptopns) that
> have strange undocumented MB devices that clash in PCI IO space.. And
> various small one-liners.
I got the following OOPS from running "alevtd -F -d -v /dev/vbi0" with
my Siemens-DVB-C on a Dual-i686-600. I'm able to reproduce this even
running a 2.6.12-rc6 without the nvidia module tainting the kernel.
Linux version 2.6.11.11 ([EMAIL PROTECTED]) (gcc version 3.3.6 (Debian
1:3.3.6-5)) #1 SMP Mon May 30 21:55:01 CEST 2005
...
saa7146: register extension 'dvb'.
ACPI: PCI interrupt :00:08.0[A] -> GSI 16 (level, low) -> IRQ 16
saa7146: found saa7146 @ mem e0968000 (revision 1, irq 16) (0x110a,0x).
DVB: registering new adapter (Fujitsu Siemens DVB-C).
adapter has MAC addr = 00:d0:5c:01:83:6c
dvb-ttpci: gpioirq unknown type=0 len=0
dvb-ttpci: info @ card 0: firm f0240009, rtsl b0250018, vid 71010068, app
8000261d
dvb-ttpci: firmware @ card 0 supports CI link layer interface
dvb-ttpci: DVB-C analog module @ card 0 detected, initializing MSP3400
saa7146_vv: saa7146 (0): registered device video0 [v4l2]
saa7146_vv: saa7146 (0): registered device vbi0 [v4l2]
DVB: registering frontend 0 (VLSI VES1820 DVB-C)...
dvb-ttpci: found av7110-0.
...
kernel BUG at drivers/media/common/saa7146_video.c:741!
invalid operand: [#1]
PREEMPT SMP
Modules linked in: rfcomm l2cap bluetooth autofs4 thermal fan button processor
ipv6 xfrm_user ipcomp ah4 ipt_state ip_conntrack iptable_filter ip_tables esp4
deflate zlib_deflate zlib_inflate twofish serpent aes_i586 blowfish des sha256
sha1 crypto_null af_key sg joydev analog ns558 gameport parport_pc parport
floppy pcspkr 3c59x mii evdev dvb_ttpci dvb_core saa7146_vv video_buf saa7146
v4l1_compat v4l2_common videodev ves1820 stv0299 tda8083 stv0297 sp8870
firmware_class ves1x93 ttpci_eeprom usbhid usb_storage i2c_piix4 uhci_hcd
usbcore intel_agp nfsd exportfs lockd sunrpc binfmt_misc dm_mod
snd_emu8000_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_seq_oss
snd_seq_midi snd_seq_midi_event snd_seq snd_util_mem snd_sbawe snd_opl3_lib
snd_sb16_dsp snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc
snd_sb16_csp snd_sb_common snd_hwdep snd_mpu401_uart snd_rawmidi snd_seq_device
snd soundcore eeprom w83781d i2c_dev i2c_sensor i2c_core nvidia agpgart
CPU:0
EIP:0060:[]Tainted: P VLI
EFLAGS: 00010246 (2.6.11.11)
EIP is at video_begin+0x1f1/0x270 [saa7146_vv]
eax: ebx: dfc22060 ecx: edx: 000a
esi: df30dce0 edi: dedfe800 ebp: de65be34 esp: de65be1c
ds: 007b es: 007b ss: 0068
Process alevtd (pid: 26938, threadinfo=de65a000 task=c417d540)
Stack: df30dce0 cfeeecb4 e0b077a0 40045612 dedfe800 de65be84 e0ae862c
dedfe800 dde21af8 0001 de65be88 de65be60 dedfe800 d8ab7c40 c1582380
dedfea68 dfc22060 df30dce0 de65bea0 dfacf9c0 dde21af8 40045612
Call Trace:
[] show_stack+0x7f/0xa0
[] show_registers+0x163/0x1d0
[] die+0x101/0x190
[] do_invalid_op+0xbc/0xd0
[] error_code+0x2b/0x30
[] saa7146_video_do_ioctl+0x59c/0xf60 [saa7146_vv]
[] video_usercopy+0x8e/0x160 [videodev]
[] fops_ioctl+0x2f/0x40 [saa7146_vv]
[] do_ioctl+0x63/0xa0
[] vfs_ioctl+0x62/0x1d0
[] sys_ioctl+0x61/0x90
[] sysenter_past_esp+0x52/0x75
Code: ae e0 b8 2a c8 ae e0 be 17 ce ae e0 89 44 24 08 89 74 24 04 e8 e1 5e 63
df 89 7c 24 04 c7 04 24 40 da ae e0 e8 d1 5e 63 df eb ad <0f> 0b e5 02 60 da ae
e0 e9 3f ff ff ff 89 f6 c7 04 24 0c ce ae
BYtE
Philipp
PS: MAINTAINTER lists http://linuxtv.org/developer/dvb.xml which is
dead.
--
/ / (_)__ __ __ Philipp Hahn
/ /__/ / _ \/ // /\ \/ /
//_/_//_/\_,_/ /_/\_\ [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
Hello! On Sun, Aug 07, 2005 at 11:47:53AM -0700, Linus Torvalds wrote: > James and gang found the aic7xxx slowdown that happened after 2.6.12, and > we'd like to get particular testing that it's fixed, so if you have a > relevant machine, please do test this. I just tried 2.6.13-rc6 after my last 2.6.11.12 and got a problem with the onboard aic7xxx on my old Gigabyte-6BXDS dual i686-600: During boot, something bad happened within domain validation and I got an oops from an unhandled NULL pointer. Since I don't have a secondary computer at home to capture the OOPS, here's the shortened stacktrace written down by hand: show_stack show_register die do_page_fault error_code ahc_set_syncrate ahc_reset_channel ahc_linux_bus_reset scsi_try_bus_reset scsi_eh_bus_reset scsi_eh_ready_devs scsi_unjam_host scsi_error_handler kernel_thread_helper After chaning the Adaptec bios setting for the Pioneer CDROM from "async" to "10 MB", I was able to boot the same kernel without problems. If somebody needs more information, I can reproduce the OOPS again and provide the missing information. BYtE Philipp -- / / (_)__ __ __ Philipp Hahn / /__/ / _ \/ // /\ \/ / //_/_//_/\_,_/ /_/\_\ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
Hi James, Dropped back to 2.6.11.1 and it hung again. I was able to get the drive back by power cycling it and then doing the scsiadd to drop and re-add the drive. I then used the bacula 'btape' tool to run some tests. It seems to be just fine with regular files, but when it hit EOM, all hell seems to break loose. There is newer firmware available for the drive, so I'll see about upgrading the firmware ASAP and see if that happens. Unfortunately, it's a SUN branded DLT and I don't have sun hardware at home. Here's the latest dmesg error logs: Attached scsi tape st0 at scsi1, channel 0, id 6, lun 0 st0: try direct i/o: yes (alignment 512 B), max page reachable by HBA 1048575 Attached scsi generic sg3 at scsi1, channel 0, id 6, lun 0, type 1 st0: Block limits 2 - 16777214 bytes. scsi1:0:6:0: Attempting to queue an ABORT message CDB: 0xa 0x0 0x0 0xfc 0x0 0x0 scsi1: At time of recovery, card was not paused >> Dump Card State Begins < scsi1: Dumping Card State in Data-out phase, at SEQADDR 0x83 Card was paused ACCUM = 0x0, SINDEX = 0xb8, DINDEX = 0xa8, ARG_2 = 0xff HCNT = 0x0 SCBPTR = 0x0 SCSISIGI[0x4]:(BSYI) ERROR[0x0] SCSIBUSL[0xc0] LASTPHASE[0x0] SCSISEQ[0x12]:(ENAUTOATNP|ENRSELI) SBLKCTL[0x2]:(SELWIDE) SCSIRATE[0x0] SEQCTL[0x10]:(FASTMODE) SEQ_FLAGS[0x20]:(DPHASE) SSTAT0[0x7]:(DMADONE|SPIORDY|SDONE) SSTAT1[0x2]:(PHASECHG) SSTAT2[0x0] SSTAT3[0x0] SIMODE0[0x0] SIMODE1[0xac]:(ENSCSIPERR|ENBUSFREE|ENSCSIRST|ENSELTIMO) SXFRCTL0[0x88]:(SPIOEN|DFON) DFCNTRL[0x4]:(DIRECTION) DFSTATUS[0x6d]:(FIFOEMP|DFTHRESH|HDONE|FIFOQWDEMP|DFCACHETH) STACK: 0x37 0x150 0x191 0x5f SCB count = 4 Kernel NEXTQSCB = 2 Card NEXTQSCB = 2 QINFIFO entries: Waiting Queue entries: Disconnected Queue entries: QOUTFIFO entries: Sequencer Free SCB List: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Sequencer SCB Info: 0 SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0x67] SCB_LUN[0x0] SCB_TAG[0x3] 1 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 2 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 3 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 4 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 5 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 6 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 7 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 8 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 9 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 10 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 11 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 12 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 13 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 14 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 15 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Pending list: 3 SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0x67] SCB_LUN[0x0] Kernel Free SCB list: 1 0 Untagged Q(6): 3 < Dump Card State Ends >> scsi1:0:6:0: Device is active, asserting ATN Recovery code sleeping Recovery code awake Timer Expired aic7xxx_abort returns 0x2003 scsi1:0:6:0: Attempting to queue a TARGET RESET message CDB: 0xa 0x0 0x0 0xfc 0x0 0x0 aic7xxx_dev_reset returns 0x2003 Recovery SCB completes scsi: Device offlined - not ready after error recovery: host 1 channel 0 id 6 lun 0 st0: Error 1 (sugg. bt 0x0, driver bt 0x0, host bt 0x1). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
James> Well, I suspect the tape is hanging the bus, from which no card James> can recover. Blech, not going to be fun to fix this sucker. James> Just to test this, can you try sending a bus reset with sgutils (from James> the debain package sg3-utils): James> sg_reset -b /dev/sg3 James> Then remove and re-add the device with James> echo scsi remove-single-device 1 0 6 0 > /proc/scsi/scsi James> echo scsi add-single-device 1 0 6 0 > /proc/scsi/scsi James> And see if that brings it back. If it doesn't I'm afraid the James> tape has the bus locked and nothing can free it. It didn't bring it back, but I'm also not at home to look at the device either. Bummers. I'll play around with this some more and get back to people when I can. Should I be moving back to 2.6.13-rc6 to get the speedup on /dev/sda anyway? Since my OS partitions are on SCSI. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
On Wed, 2005-08-10 at 11:28 -0400, John Stoffel wrote: > Is there any more info I can provide here for you? dmesg output? > Here's the latest output from dmesg with the lockup of the drive, > which takes a power cycle to clear now. Well, I suspect the tape is hanging the bus, from which no card can recover. Just to test this, can you try sending a bus reset with sgutils (from the debain package sg3-utils): sg_reset -b /dev/sg3 Then remove and re-add the device with echo scsi remove-single-device 1 0 6 0 > /proc/scsi/scsi echo scsi add-single-device 1 0 6 0 > /proc/scsi/scsi And see if that brings it back. If it doesn't I'm afraid the tape has the bus locked and nothing can free it. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
Hi James, As a test, I dropped back to 2.6.12.1 and the drive hung again last night while trying to do backups, so I suspect that I might have controller or tape drive problems of some sort. I'll also try to go back to 2.6.12-rc6 as well and see how that works out. My next step is to try and get the tape drive to be read/written with just plain dd or tar and to see if that helps or not. It could also be my backup software (bacula) is doing something strange to the drive when it writes data, but I doubt it. Is there any more info I can provide here for you? dmesg output? Here's the latest output from dmesg with the lockup of the drive, which takes a power cycle to clear now. Linux version 2.6.12.1 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #63 SMP Sat Jul 16 00:15:30 EDT 2005 BIOS-provided physical RAM map: BIOS-e820: - 000a (usable) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 2fffe000 (usable) BIOS-e820: 2fffe000 - 3000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fee0 - fee1 (reserved) BIOS-e820: ffe0 - 0001 (reserved) 767MB LOWMEM available. found SMP MP-table at 000fe710 On node 0 totalpages: 196606 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 192510 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 DMI 2.2 present. ACPI: RSDP (v000 DELL ) @ 0x000fdee0 ACPI: RSDT (v001 DELLWS 610 0x0002 ASL 0x0061) @ 0x000fdef4 ACPI: FADT (v001 DELLWS 610 0x0002 ASL 0x0061) @ 0x000fdf20 ACPI: MADT (v001 DELLWS 610 0x0002 ASL 0x0061) @ 0x000fdf94 ACPI: DSDT (v001 DELLdt_ex 0x1000 MSFT 0x010b) @ 0x ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:7 APIC version 17 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 6:7 APIC version 17 ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x4]) ACPI: NMI not connected to LINT 1! ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 17, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 3000 (gap: 3000:cec0) Built 1 zonelists Kernel command line: root=/dev/sda2 ro console=tty0 mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 547.379 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 774076k/786424k available (2740k kernel code, 11784k reserved, 1234k data, 228k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 1081.34 BogoMIPS (lpj=540672) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0383fbff CPU: After vendor identify, caps: 0383fbff CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU: After all inits, caps: 0383fbff 0040 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. CPU0: Intel Pentium III (Katmai) stepping 03 Booting processor 1/1 eip 2000 Initializing CPU#1 Calibrating delay loop... 1089.53 BogoMIPS (lpj=544768) CPU: After generic identify, caps: 0383fbff CPU: After vendor identify, caps: 0383fbff CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU: After all inits, caps: 0383fbff 0040 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#1. CPU1: Intel Pentium III (Katmai) stepping 03 Total of 2 processors activated (2170.88 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 pin1=2 pin2=-1 checking TSC synchronization across 2 CPUs: passed. Brought up 2 CPUs CPU0 attaching sched-domain: domain 0: span 03 groups: 01 02 CPU1 attaching sched-domain: domain 0: span 03 groups: 02 01 NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfca1e, last bus=3 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI:
Re: Linux-2.6.13-rc6: aic7xxx testers please..
On Tue, 2005-08-09 at 16:12 -0400, John Stoffel wrote: > Thank you for looking into this with me, I really appreciate it. I'm > kinda stumped why this suddenly started happening, but it could be > hardware related of course... Well ... there's something going on that your posted dmesg's don't seem to cover. This: > Vendor: SUN Model: DLT7000 Rev: 1E48 > Type: Sequential-Access ANSI SCSI revision: 02 >target1:0:6: asynchronous. >target1:0:6: Beginning Domain Validation >target1:0:6: wide asynchronous. >target1:0:6: Domain Validation skipping write tests >target1:0:6: FAST-10 WIDE SCSI 20.0 MB/s ST (100 ns, offset 8) >target1:0:6: Ending Domain Validation Say everything went OK with DV and the drive attaches wide and at 10MHz. But in your previous posting, the aic proc routines said this: > Target 6 Negotiation Settings > User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit) > Goal: 20.000MB/s transfers (10.000MHz, offset 8, 16bit) > Curr: 3.300MB/s transfers > Channel A Target 6 Lun 0 Settings > Commands Queued 1065 > Commands Active 0 > Command Openings 1 > Max Tagged Openings 0 > Device Queue Frozen Count 0 Which is the AIC driver's way of saying narrow async. So something must have happened during the 1065 I/Os to cause this. Hopefully that something left a trace in the logs. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
> "James" == James Bottomley <[EMAIL PROTECTED]> writes: Thank you for looking into this with me, I really appreciate it. I'm kinda stumped why this suddenly started happening, but it could be hardware related of course... James> So basically the problem is on scsi1 with the tape device, which James> apparently negotiates only narrow async? It's not a performance problem, it's a lockup problem. I use bacula to make my backups using the DLT7000 as my media. But the tape drives hangs, it's hung now so that I can't do my backups. James> What do the domain validation messages say about this device? James> They should be in dmesg. I'm fairly certain that DLT tapes do James> better than narrow async. The drive should be able to do 10MBytes/sec to the interface, the drive itself can only do 5Mbytes/sec to the media, but with 2:1 compression and an 8MB buffer on the drive, it likes to be fed data as quickly as it can. Here's the validation results for my two disks and tape drive: scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs target0:0:0: asynchronous. Vendor: COMPAQModel: HC01841729Rev: 3208 Type: Direct-Access ANSI SCSI revision: 02 scsi0:A:0:0: Tagged Queuing enabled. Depth 32 target0:0:0: Beginning Domain Validation target0:0:0: wide asynchronous. target0:0:0: Domain Validation skipping write tests target0:0:0: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 15) target0:0:0: Ending Domain Validation Vendor: COMPAQModel: BD018222CARev: B016 Type: Direct-Access ANSI SCSI revision: 02 target0:0:1: asynchronous. scsi0:A:1:0: Tagged Queuing enabled. Depth 32 target0:0:1: Beginning Domain Validation target0:0:1: wide asynchronous. target0:0:1: Domain Validation skipping write tests target0:0:1: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 63) target0:0:1: Ending Domain Validation scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs Vendor: SUN Model: DLT7000 Rev: 1E48 Type: Sequential-Access ANSI SCSI revision: 02 target1:0:6: asynchronous. target1:0:6: Beginning Domain Validation target1:0:6: wide asynchronous. target1:0:6: Domain Validation skipping write tests target1:0:6: FAST-10 WIDE SCSI 20.0 MB/s ST (100 ns, offset 8) target1:0:6: Ending Domain Validation st: Version 20050501, fixed bufsize 32768, s/g segs 256 Attached scsi tape st0 at scsi1, channel 0, id 6, lun 0 st0: try direct i/o: yes (alignment 512 B), max page reachable by HBA 1048575 SCSI device sda: 35566000 512-byte hdwr sectors (18210 MB) SCSI device sda: drive cache: write through SCSI device sda: 35566000 512-byte hdwr sectors (18210 MB) SCSI device sda: drive cache: write through sda: sda1 sda2 sda3 sda4 < sda5 sda6 > Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 SCSI device sdb: 35565080 512-byte hdwr sectors (18209 MB) SCSI device sdb: drive cache: write through SCSI device sdb: 35565080 512-byte hdwr sectors (18209 MB) SCSI device sdb: drive cache: write through sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 > Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
On Tue, 2005-08-09 at 15:35 -0400, John Stoffel wrote: > Attached devices: > Host: scsi0 Channel: 00 Id: 00 Lun: 00 > Vendor: COMPAQ Model: HC01841729 Rev: 3208 > Type: Direct-AccessANSI SCSI revision: 02 > Host: scsi0 Channel: 00 Id: 01 Lun: 00 > Vendor: COMPAQ Model: BD018222CA Rev: B016 > Type: Direct-AccessANSI SCSI revision: 02 > Host: scsi1 Channel: 00 Id: 06 Lun: 00 > Vendor: SUN Model: DLT7000 Rev: 1E48 > Type: Sequential-AccessANSI SCSI revision: 02 > Host: scsi2 Channel: 00 Id: 00 Lun: 00 > Vendor: EPSONModel: Stylus Storage Rev: 1.00 > Type: Direct-AccessANSI SCSI revision: 02 So basically the problem is on scsi1 with the tape device, which apparently negotiates only narrow async? What do the domain validation messages say about this device? They should be in dmesg. I'm fairly certain that DLT tapes do better than narrow async. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
Hi Linus & James, I've still got problems under 2.6.13-rc6 with my DLT7000 drive on an AIC7880 builtin controller. Here's the message I got in dmesg. My system is a heavily upgraded Debian/unstable with dual 550mhz Xeon processors and 768mb of RAM, dual SCSI busses. The annoying problem is that I have to (sometimes) power cycle the DLT 7000 tape drive to get it back onto the bus. So I guess it could be a tape drive problem, esp since I've got my root disk on /dev/sda, which is also a builtin AIC7890 controller. Sometimes I'm able to do a 'scsiadd -r 1 0 6 0' and then a 'scsiadd -a 1 0 6 0' to get it working again. Details about my system: > cat /proc/version Linux version 2.6.13-rc6 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #73 SMP Mon Aug 8 09:58:30 EDT 2005 > lspci :00:00.0 Host bridge: Intel Corp. 440GX - 82443GX Host bridge :00:01.0 PCI bridge: Intel Corp. 440GX - 82443GX AGP bridge :00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) :00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) :00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) :00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02) :00:0d.0 RAID bus controller: Triones Technologies, Inc. HPT302 (rev 01) :00:0e.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06) :00:11.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24) :00:13.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) :01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 82) :02:06.0 PCI bridge: Hint Corp HB6 Universal PCI-PCI bridge (non-transparent mode) (rev 13) :02:0a.0 SCSI storage controller: Adaptec AHA-2940U2/U2W / 7890/7891 :02:0e.0 SCSI storage controller: Adaptec AIC-7880U (rev 01) :03:08.0 USB Controller: NEC Corporation USB (rev 41) :03:08.1 USB Controller: NEC Corporation USB (rev 41) :03:08.2 USB Controller: NEC Corporation USB 2.0 (rev 02) :03:0b.0 FireWire (IEEE 1394): Texas Instruments TSB12LV26 IEEE-1394 Controller (Link) > cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: COMPAQ Model: HC01841729 Rev: 3208 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: COMPAQ Model: BD018222CA Rev: B016 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 06 Lun: 00 Vendor: SUN Model: DLT7000 Rev: 1E48 Type: Sequential-AccessANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 00 Lun: 00 Vendor: EPSONModel: Stylus Storage Rev: 1.00 Type: Direct-AccessANSI SCSI revision: 02 > cat /proc/scsi/aic7xxx/0 Adaptec AIC7xxx driver version: 6.2.36 Adaptec aic7890/91 Ultra2 SCSI adapter aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs Allocated SCBs: 36, SG List Length: 128 Serial EEPROM: 0x03bb 0x03bb 0x03bb 0x03bb 0x03bb 0x03bb 0x03bb 0x03bb 0x03bb 0x03bb 0x03bb 0x03bb 0x03bb 0x03bb 0x03bb 0x03bb 0x18a6 0x1c5c 0x2807 0x0010 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x98be Target 0 Negotiation Settings User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) Goal: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) Curr: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) Channel A Target 0 Lun 0 Settings Commands Queued 74229 Commands Active 0 Command Openings 32 Max Tagged Openings 32 Device Queue Frozen Count 0 Target 1 Negotiation Settings User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) Goal: 40.000MB/s transfers (20.000MHz, offset 63, 16bit) Curr: 40.000MB/s transfers (20.000MHz, offset 63, 16bit) Channel A Target 1 Lun 0 Settings Commands Queued 29 Commands Active 0 Command Openings 32 Max Tagged Openings 32 Device Queue Frozen Count 0 Target 2 Negotiation Settings User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) Target 3 Negotiation Settings User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) Target 4 Negotiation Settings User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) Target 5 Negotiation Settings User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) Target 6 Negotiation Settings User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) Target 7 Negotiation Settings User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) Target 8 Negotiation Settings User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) Target 9 Negotiation Settings User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) Target 10 Negotiation Settings User: 80.000MB/s t
Re: Linux-2.6.13-rc6: aic7xxx testers please..-deadlock
"art" <[EMAIL PROTECTED]> wrote: > > kernel 2.6.13-rc1-git7 to 2.6.13-rc5 transfer 72MB/s on aha19160 with 15k > rpm seagate with reiserfs3 but possible deadlock in heavy IO - rsync > ~5-small files from /mnt/seagate15k/a to /mnt/seagate15k/b ends in > middle with deadlock of rsync (3 instances), pdflush, and gam_server all > of them in uninteruptible state -- root cannot kill this deadlocked > uninterruptibles, so reboot by reset Please ensure that CONFIG_MAGIC_SYSRQ=y amd that /proc/sysrq is 1 and when the deadlock happens, do ALT-SYSRQ-T or `echo t > /proc/sysrq-trigger' then get us the output of `dmesg -s 100', thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
On Sunday 07 August 2005 20:47, Linus Torvalds wrote: > > James and gang found the aic7xxx slowdown that happened after 2.6.12, and > we'd like to get particular testing that it's fixed, so if you have a > relevant machine, please do test this. > I'm using the aic7xxx driver, and although I haven't had any trouble with previous kernels and this driver I thought I'd report anyway that everything seems to be working ok with -rc6. At least this means you haven't broken a previously working setup :-) Details about my hardware below : $ uname -a Linux dragon 2.6.13-rc6 #1 Mon Aug 8 18:07:08 CEST 2005 i686 unknown unknown GNU/Linux $ /sbin/lspci -vvv <...> 00:0b.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02) Subsystem: Adaptec 29160N Ultra160 SCSI Controller Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- $ dmesg <...> [ 27.874038] scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 [ 27.874041] [ 27.874043] aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs [ 27.874046] [ 27.884187] kobject host0: registering. parent: :00:0b.0, set: devices [ 27.884206] kobject host0: registering. parent: scsi_host, set: class_obj [ 27.884226] kobject host0: registering. parent: spi_host, set: class_obj [ 27.884240] kobject target0:0:0: registering. parent: host0, set: devices [ 27.884248] kobject target0:0:0: registering. parent: spi_transport, set: class_obj [ 43.122408] kobject : cleaning up [ 43.122436] kobject target0:0:0: cleaning up [ 43.122439] kobject target0:0:0: cleaning up [ 43.122445] kobject target0:0:1: registering. parent: host0, set: devices [ 43.122455] kobject target0:0:1: registering. parent: spi_transport, set: class_obj [ 43.378585] kobject : cleaning up [ 43.378600] kobject target0:0:1: cleaning up [ 43.378603] kobject target0:0:1: cleaning up [ 43.378609] kobject target0:0:2: registering. parent: host0, set: devices [ 43.378617] kobject target0:0:2: registering. parent: spi_transport, set: class_obj [ 43.634760] kobject : cleaning up [ 43.634773] kobject target0:0:2: cleaning up [ 43.634777] kobject target0:0:2: cleaning up [ 43.634782] kobject target0:0:3: registering. parent: host0, set: devices [ 43.634791] kobject target0:0:3: registering. parent: spi_transport, set: class_obj [ 43.890919] kobject : cleaning up [ 43.890932] kobject target0:0:3: cleaning up [ 43.890936] kobject target0:0:3: cleaning up [ 43.890941] kobject target0:0:4: registering. parent: host0, set: devices [ 43.890949] kobject target0:0:4: registering. parent: spi_transport, set: class_obj [ 43.896324] Vendor: PIONEER Model: DVD-ROM DVD-305 Rev: 1.03 [ 43.899023] Type: CD-ROM ANSI SCSI revision: 02 [ 43.901656] target0:0:4: asynchronous. [ 43.904268] target0:0:4: Beginning Domain Validation [ 43.909476] target0:0:4: Domain Validation skipping write tests [ 43.912470] target0:0:4: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 16) [ 43.917610] target0:0:4: Ending Domain Validation [ 43.920192] kobject 0:0:4:0: registering. parent: target0:0:4, set: devices [ 43.920207] kobject 0:0:4:0: registering. parent: scsi_device, set: class_obj [ 43.920231] kobject target0:0:5: registering. parent: host0, set: devices [ 43.920248] kobject target0:0:5: registering. parent: spi_transport, set: class_obj [ 43.925135] Vendor: PLEXTOR Model: CD-R PX-W1210S Rev: 1.01 [ 43.927873] Type: CD-ROM ANSI SCSI revision: 02 [ 43.930543] target0:0:5: asynchronous. [ 43.933130] target0:0:5: Beginning Domain Validation [ 43.937224] target0:0:5: Domain Validation skipping write tests [ 43.940045] target0:0:5: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 16) [ 43.944099] target0:0:5: Ending Domain Validation [ 43.946629] kobject 0:0:5:0: registering. parent: target0:0:5, set: devices [ 43.946640] kobject 0:0:5:0: registering. parent: scsi_device, set: class_obj [ 43.946656] kobject target0:0:6: registering. parent: host0, set: devices [ 43.946664] kobject target0:0:6: registering. parent: spi_transport, set: class_obj [ 43.947795] Vendor: IBM Model: DDYS-T36950N Rev: S96H [ 43.950487] Type: Direct-Access ANSI SCSI revision: 03 [ 43.953091] target0:0:6: asynchronous. [ 43.955613] scsi0:A:6:0: Tagged Queuing enabled. Depth 250 [ 43.958183] target0:0:6: Beginning Domain Validation [ 43.963544] target0:0:6: wide asynchronous. [ 43.970778] target0:0:6: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 63) [ 43.982801] target0:0:6: Ending Domain Validation [ 43.985348] kobject 0:0:6:0: registering. parent: target0:0:6, set: devices [ 43.985360] kobject 0:0:6:0: registering. parent: scsi_device, set: class_obj [ 43.
Re: Linux-2.6.13-rc6: aic7xxx testers please..-deadlock
kernel 2.6.13-rc1-git7 to 2.6.13-rc5 transfer 72MB/s on aha19160 with 15k rpm seagate with reiserfs3 but possible deadlock in heavy IO - rsync ~5-small files from /mnt/seagate15k/a to /mnt/seagate15k/b ends in middle with deadlock of rsync (3 instances), pdflush, and gam_server all of them in uninteruptible state -- root cannot kill this deadlocked uninterruptibles, so reboot by reset [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
Linus Torvalds <[EMAIL PROTECTED]> wrote: >James and gang found the aic7xxx slowdown that happened after 2.6.12, and >we'd like to get particular testing that it's fixed, so if you have a >relevant machine, please do test this. with me, rc6 lasted 18 hours: reboot system boot 2.6.13-rc6 Mon Aug 8 16:52 (00:11) dth pts/0zaphod.dth.net Sun Aug 7 22:14 - crash (18:37) scsi1:0:14:0: Attempting to abort cmd 810038f6dd40: 0x2a 0x0 0x3 0x91 0x45 0x10 0x0 0x0 0x1 0x0 scsi1: At time of recovery, card was not paused >> Dump Card State Begins < scsi1: Dumping Card State at program address 0x13 Mode 0x11 Card was paused For more info regarding kern.log etc: http://newsgate.newsserver.nl/kernel/ 2.6.12-mm1 survived 18+ days ! Can it be something with acpi that somehow loses an interrupt ? This machine really does some heavy network/disktraffic. Danny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
On Mon, Aug 08, 2005 at 12:14:43AM +0300, Dumitru Ciobarcianu wrote: > ??n data de Du, 07-08-2005 la 11:47 -0700, Linus Torvalds a scris: > > Luming Yu: > > [ACPI] revert Embedded Controller to polling-mode by default (ala 2.6.12) > > [ACPI] CONFIG_ACPI_HOTKEY is now "n" by default > > IMHO you really need then to make acpi_specific_hotkey the default or at > least mention it in the release notes or you'll have tons of people > screaming that the specific module does not work anymore. > I found out about it after my toshiba_acpi module stopped working and I > noticed a small change in the development acpi tree documentation > mentioning acpi_specific_hotkey ... What was the reasoning behind this UI design decision anyway? If you don't enable the generic hotkey code, it seems _stupid_ to require a magic boot-time config option in order to enable the specific hotkey code. Yes, at the very least we should do is mention this brain-damaged UI in the release notes, since otherwise users will get the warning, recompile without the generic hotkey support, and then be confused when the IBM driver still complains that it can't start because we're using generic hotkey support --- which is not enabled! The developer/user will at this point either (a) start diving into the kernel sources and marvelling at the user-hostile UI design decisions involved, or (b) start screaming and pounding their head against a brick wall. At least in the case of the IBM driver, it provides _far_ more functionality than the generic hotkey option (ultrabay control, docking control, bluetooth enable/disable, fan control, etc.) so if it is compiled it, it should by default take precedence over the hotkey code. I'm not convinced there should be any need for a mysterious command-line option at all, but if it is present, it should only provide an override in case both the generic and the hotkey-specific drivers are compiled in. If they are modules, the first module to load should take precedence, and if they are both compiled in, the laptop-specific should take precendence unless there is a boot-time option to the contrary. Len, am I missing something, or will you accept a patch ? - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
Linus> James and gang found the aic7xxx slowdown that happened after Linus> 2.6.12, and we'd like to get particular testing that it's Linus> fixed, so if you have a relevant machine, please do test this. This might explain why my DLT7000 has been dropping off the bus at times and requiring a full reboot and/or power cycle of the drive to get it back working again. More details once I've compiled and re-loaded using this. John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
În data de Du, 07-08-2005 la 11:47 -0700, Linus Torvalds a scris: > Luming Yu: > [ACPI] revert Embedded Controller to polling-mode by default (ala 2.6.12) > [ACPI] CONFIG_ACPI_HOTKEY is now "n" by default IMHO you really need then to make acpi_specific_hotkey the default or at least mention it in the release notes or you'll have tons of people screaming that the specific module does not work anymore. I found out about it after my toshiba_acpi module stopped working and I noticed a small change in the development acpi tree documentation mentioning acpi_specific_hotkey ... -- Cioby - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
On Sun, 2005-08-07 at 13:50 -0700, Linus Torvalds wrote: > > On Sun, 7 Aug 2005, Lee Revell wrote: > > > > It looks like CONFIG_4KSTACKS has gone away (IOW 8K stacks are no longer > > an option). But now I get this ominous warning when I compile > > ndiswrapper: > > It's still there, and it (still) depends on DEBUG_KERNEL. Nothing should > have changed afaik.. OK, thanks, sorry for the noise. I remember there was talk recently of 4K stacks for everyone and was afraid it had already happened. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
On Sun, 7 Aug 2005, Lee Revell wrote: > > It looks like CONFIG_4KSTACKS has gone away (IOW 8K stacks are no longer > an option). But now I get this ominous warning when I compile > ndiswrapper: It's still there, and it (still) depends on DEBUG_KERNEL. Nothing should have changed afaik.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
On Sun, 2005-08-07 at 11:47 -0700, Linus Torvalds wrote: > James and gang found the aic7xxx slowdown that happened after 2.6.12, and > we'd like to get particular testing that it's fixed, so if you have a > relevant machine, please do test this. > > There are other fixes too, a number of them reverting (at least for now) > patches that people had problems with. In general, anybody who has > reported regressions since 2.6.12, please re-test with -rc6 and report > back (even if, or perhaps _particularly_ if, no change to the regression). It looks like CONFIG_4KSTACKS has gone away (IOW 8K stacks are no longer an option). But now I get this ominous warning when I compile ndiswrapper: *** WARNING: Kernel seems to have 4K size stack option (CONFIG_4KSTACKS) removed; many Windows drivers will need at least 8K size stacks. You should read wiki about 4K size stack issue. Don't complain about crashes until you resolve this As ndiswrapper seems to be the only option for many wireless chipsets, this certainly looks like it will lead to regressions. Why was this option removed? It's pretty clear that lots of out of tree drivers still require it. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
Linus Torvalds wrote: > In general, anybody who has reported regressions since 2.6.12, please > re-test with -rc6 and report back > ... > Herbert Xu: > tcp: fix TSO cwnd caching bug The tcp_output panic bug seems to be fixed. I'm referring to: http://lkml.org/lkml/2005/8/7/63 -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] "Math is hard, let's go shopping!" http://www.iki.fi/shd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux-2.6.13-rc6: aic7xxx testers please..
James and gang found the aic7xxx slowdown that happened after 2.6.12, and we'd like to get particular testing that it's fixed, so if you have a relevant machine, please do test this. There are other fixes too, a number of them reverting (at least for now) patches that people had problems with. In general, anybody who has reported regressions since 2.6.12, please re-test with -rc6 and report back (even if, or perhaps _particularly_ if, no change to the regression). Apart from some reverts and the aic7xxx performance regression fix, there's arm and ppc updates, and some PCI resource allocation updates that hopefully will reduce the number of machines (especially laptopns) that have strange undocumented MB devices that clash in PCI IO space.. And various small one-liners. The appended shortlog/diffstat gives more some more specific insight.. Linus --- shortlog --- Alasdair G Kergon: dm-raid locking fix Alexander Nyberg: x86-64: use proper VM_FAULT_xxx macros Alexey Starikovskiy: [ACPI] restore /proc/acpi/button/ (ala 2.6.12) Andi Kleen: x86_64: ignore machine checks from boot time Andrew Morton: [SCSI] fc4 warning fix revert "timer exit cleanup" REPORTING-BUGS: track regressions __bio_clone() dead comment Aristeu Sergio Rozanski Filho: ppc32: 8xx: convert fec driver to use work_struct ppc32: 8xx: using dma_alloc_coherent() instead consistent_alloc() ppc32: 8xx: fec: fix interrupt handler prototypes ppc32: 8xx fix CPM ethernet description ppc32: 8xx restrict ENET_BIG_BUFFERS option ppc32: 8xx kill unused variable in commproc Ben Dooks: ARM: 2832/1: BAST - limit clock-rate for IIC bus Benjamin Herrenschmidt: Remove suspend() calls from shutdown path Catalin Marinas: ARM: 2841/1: Fix VFP +/-0 case for doubles addition Christoph Hellwig: [SPARC]: Fix up sleep_on() removal in vfc driver. Daniel Jacobowitz: x86_64: fix 32-bit thread debugging David Brownell: USB: ehci: microframe handling fix David Gibson: Fix hugepage crash on failing mmap() David Howells: Keys: Fix key management syscall interface bugs Error during attempt to join key management session can leave semaphore pinned Destruction of failed keyring oopses David S. Miller: tcp: fix TSO sizing bugs [IPV4]: Fix memory leak during fib_info hash expansion. David Shaohua Li: [ACPI] PCI interrupt link suspend/resume - revert to 2.6.12 behaviour [ACPI] S3 resume: avoid kmalloc() might_sleep oops symptom Deepak Saxena: ARM: 2839/1: Remove XScale cache and TLB locking code ARM: 2835/1: Add UPF_SKIP_TEST to IXP4xx serial ports Dominik Brodowski: pci and yenta: pcibios_bus_to_resource Dominik Hackl: crc32.c typo fix Eric W. Biederman: i386 voyager: Add machine_shutdown i386 visws: Add machine_shutdown and emergency_restart x86_64 bootmem: sparse_mem/kexec merge bug. Hal Rosenstock: [IPoIB] Handle sending of unicast RARP responses Haren Myneni: Xmon bug fix for soft-reset Herbert Xu: tcp: fix TSO cwnd caching bug Hugh Dickins: fix VmSize and VmData after mremap Ian Campbell: ARM: 2833/2: Remove support for WDIOF_MAGICCLOSE from sa1100-wdt Ingo Molnar: Fix semundo lock leakage Ivan Kokshaysky: increase PCIBIOS_MIN_IO on x86 ACPI: increase PCIBIOS_MIN_IO on x86 Fix restore of 64-bit PCI BAR's Jack Hammer: [SCSI] ServeRAID V7.12.02 James Bottomley: [SCSI] aic7xxx: fix bug in DT handing [SCSI] aic7xxx: final fixes for DT handling [SCSI] fix aic7xxx performance issues since 2.6.12-rc2 fix voyager compile after machine_emergency_restart breakage Jens Axboe: cfq-iosched: fix problem with barriers and max_depth == 1 Jim Keniston: Add Documentation/kprobes.txt John McCutchan: inotify delete race fix Clean up inotify delete race fix John W. Linville: PCI: restore BAR values after D3hot->D0 for devices that need it Kai Makisara: [SCSI] Fix SCSI tape oops at module removal Len Brown: [ACPI] fix 64-bit build warning in processor_idle.c /home/lenb/src/to-linus branch 'acpi-2.6.12' [ACPI] delete Warning: Encountered executable code at module level, [AE_NOT_CONFIGURED] /home/lenb/src/to-linus-stable branch 'acpi-2.6.12' Merge ../to-linus-stable Linda Xie: [SCSI] scsi/ibmvscsi/srp.h: Fix a wrong type code used for SRP_LOGIN_REJ Linus Torvalds: pci: make bus resource start address override minimum IO address Fix up recent get_user_pages() handling Merge master.kernel.org:/home/rmk/linux-2.6-arm Merge master.kernel.org:/.../lenb/to-linus It wasn't just x86-64 that had hardcoded VM_FAULT_xxx numbers Merge head 'for-linus' of master.kernel.org:/.../roland/infiniband Merge master.kernel.org:/home/rmk/linux-2.6-arm Merge master.kernel.org:/.../lenb/to-linus Merge master.kernel.org:/home/rmk/linux-2.6-arm Merge master.kernel.org:/.../jejb/scsi-for-linus-2.6 Merge master.kernel.org:/.../davem/sparc-2.6 Merge master.kernel.org:/.../davem/net-2.6 Add fakey 'deflateBound()' function
