Re: [PATCH] dynamic IP support for 2.4.0 (SIOCKILLADDR)
On Mon, 29 Jan 2001, Jamie Lokier wrote: > Unfortunately getting the same IP is rare now, so I've been toying with > running a PPP tunnel through a fixed host out on the net. The tunnel > would be dropped and recreated with each new connection. My local link > IP would change, but the tunnel IP would not so connections to other > places, ssh etc. would all be from the tunnel IP. ciped is great for this. I use it to tunnel ssh from my home dialup to work. Very stable, and with cipe's shared keys, there's nothing too taxing about setting it up. I just have a call to /etc/init.d/ciped restart in my ppp up script. freeswan was another way I looked at , but ip/sec was horrible at the time and didn't (maybe still doesn't) deal with dynamic ip assignment nicely. Cheers, Mark -- +-----+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dynamic IP support for 2.4.0 (SIOCKILLADDR)
On Mon, 29 Jan 2001, Jamie Lokier wrote: Unfortunately getting the same IP is rare now, so I've been toying with running a PPP tunnel through a fixed host out on the net. The tunnel would be dropped and recreated with each new connection. My local link IP would change, but the tunnel IP would not so connections to other places, ssh etc. would all be from the tunnel IP. ciped is great for this. I use it to tunnel ssh from my home dialup to work. Very stable, and with cipe's shared keys, there's nothing too taxing about setting it up. I just have a call to /etc/init.d/ciped restart in my ppp up script. freeswan was another way I looked at , but ip/sec was horrible at the time and didn't (maybe still doesn't) deal with dynamic ip assignment nicely. Cheers, Mark -- +-+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide-probe.c:400: `rtc_lock' undeclared and /lib/modules/..../build
On Tue, 7 Nov 2000, Tomasz Motylewski wrote: > 2.2.18pre19: > ide-probe.c:400: `rtc_lock' undeclared (first use this function) > ide-probe.c:400: (Each undeclared identifier is reported only once > ide-probe.c:400: for each function it appears in.) See the attached patch. Just declares it as an extern spinlock_t, as per a boatload of other places in the kernel. Mark -- +-----+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ --- linux/drivers/block/ide-probe.c.origSat Nov 4 06:32:43 2000 +++ linux/drivers/block/ide-probe.c Sat Nov 4 06:32:52 2000 @@ -43,6 +43,8 @@ #include #include +extern spinlock_t rtc_lock; + #include "ide.h" static inline void do_identify (ide_drive_t *drive, byte cmd)
Re: Possible critical VIA vt82c686a chip bug
On Mon, 30 Oct 2000, Vojtech Pavlik wrote: > I don't think so. If you check the code paths more closely, you'll see > that the timer is used even in the fast TSC case, the error causes by > too big 'count' variable propagates up to the TSC routine. That's where > I started hunting for the bug. > > So no, it wasn't a placebo effect. Put a printk() in the fix statement > to see if it's triggered. Mmmm. Okay. Maybe I fixed the 'wrong' place, but the place I 'fixed' was in do_slow_gettimeoffset, which is inside #ifndef CONFIG_X86_TSC. I'll compile with a printk in there at home tonight though. *peers more closely* Ho-ho. I see. There's one further down in the timer interrupt itself. Oops. My bad. Cheers, Mark -- +-----+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug
On Mon, 30 Oct 2000, Vojtech Pavlik wrote: I don't think so. If you check the code paths more closely, you'll see that the timer is used even in the fast TSC case, the error causes by too big 'count' variable propagates up to the TSC routine. That's where I started hunting for the bug. So no, it wasn't a placebo effect. Put a printk() in the fix statement to see if it's triggered. Mmmm. Okay. Maybe I fixed the 'wrong' place, but the place I 'fixed' was in do_slow_gettimeoffset, which is inside #ifndef CONFIG_X86_TSC. I'll compile with a printk in there at home tonight though. *peers more closely* Ho-ho. I see. There's one further down in the timer interrupt itself. Oops. My bad. Cheers, Mark -- +-+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: CDROMPLAYTRKIND in 2.4.X
On Tue, 17 Oct 2000, Thomas Molina wrote: > On Tue, 17 Oct 2000, Jens Axboe wrote: > > On Tue, Oct 17 2000, Thomas Molina wrote: > > > CD Recording seems to work correctly under 2.4.0-test10-pre3. I'm using > > > cdrecord 1.9 with a Phillips CDD3610. However, playing back an audio cd > > > using cdp gives the following error: > > > > > > sr0: CDROM (ioctl) reports ILLEGAL REQUEST. > > > CDROMPLAYTRKIND: Operation not supported > > > > cd app players can't use CDROMPLAYTRKIND and expect it to always work. > > It will fail on most setups with ide-scsi > > Judging from past history I'd say the users are going to be told to bug > the app maintainers to tell them it's broken Jim. It always comes out > sounding a bit harsh. Similar situation with 2.2.x / ide-scsi. The Gnome planel applet just tries CDROMPLAYTRKIND, and fails. Firing off gtcd will let you play the cd, because it (presumably) does things 'right'. Haven't been bothered enough by the panel applet's glitch to fix it myself - I don't leave it running because of the periodic disk checking and corresponding syslog spammage. Regards, Mark -- +-+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: CDROMPLAYTRKIND in 2.4.X
On Tue, 17 Oct 2000, Thomas Molina wrote: On Tue, 17 Oct 2000, Jens Axboe wrote: On Tue, Oct 17 2000, Thomas Molina wrote: CD Recording seems to work correctly under 2.4.0-test10-pre3. I'm using cdrecord 1.9 with a Phillips CDD3610. However, playing back an audio cd using cdp gives the following error: sr0: CDROM (ioctl) reports ILLEGAL REQUEST. CDROMPLAYTRKIND: Operation not supported cd app players can't use CDROMPLAYTRKIND and expect it to always work. It will fail on most setups with ide-scsi Judging from past history I'd say the users are going to be told to bug the app maintainers to tell them it's broken Jim. It always comes out sounding a bit harsh. Similar situation with 2.2.x / ide-scsi. The Gnome planel applet just tries CDROMPLAYTRKIND, and fails. Firing off gtcd will let you play the cd, because it (presumably) does things 'right'. Haven't been bothered enough by the panel applet's glitch to fix it myself - I don't leave it running because of the periodic disk checking and corresponding syslog spammage. Regards, Mark -- +-+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: failure to blank CDRWs (2.2.18pre15 smp ide-scsi hp7100i)
On Mon, 16 Oct 2000, Douglas Gilbert wrote: > Sg has an ioctl called SG_SET_TRANSFORM which is only > relevant to the ide-scsi driver. As far as I know, no > applications use it. Still it is not clear why Mark's > system would work on a UP machine but fail on a SMP box. Hi Douglas, Jörg, all, I just finished compiling cdrecord-1.8.1 with debug enabled. The two attached log files are from the hp7100i / smp / 2.2.18pre15, and the ricoh 9060 / up /2.2.18pre15. Exact same cdrw media. # ./cdrecord -debug dev=1,0,0 blank=all 2>&1 | tee log.(hp7100|ricoh) I should note that the ricoh when blanking took a whole 5-6 seconds, so it didn't blank the whole disk. I guess it's being 'clever' and knew the disk was blank, and just 'made sure'. I just finished writing a 650Mb iso to the cdrw in question, so it does appear to still be okay. Looking at the traces and where they diverge it does appear to be shortly after cdrecord attempts to read ATIP data - which the Ricoh supports, and the HP7100i doesn't. I'm guessing that it's something in cdrecord making a bad assumption if ATIP isn't available, though I'll have to look further into this. Thanks to everyone who has taken time looking at this so far. It's appreciated. Cheers, Mark -- +-----+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ fs: 4194304 buflen: 4198400 ./cdrecord: shared memory segment allocated: 48169 ./cdrecord: shared memory segment attached: 40149000 buf: 40149000 bufend: 4054A000, buflen: 4198400 buf: 40149000 bufend: 4054A000, buflen: 4198400 (align 0) SCSI buffer size: 32768 dev: 1,0,0 speed: -1 fs: -1 Cdrecord 1.8.1 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling TOC Type: 1 = CD-ROM scsidev: '1,0,0' scsibus: 1 target: 0 lun: 0 l1: 0xA05 l2: 0x0 Bus: 0 Target: 5 Lun: 0 Chan: 0 Ino: 10 l1: 0x3200 l2: 0x0 Bus: 1 Target: 0 Lun: 0 Chan: 0 Ino: 50 Using libscg version 'schily-0.1' scsi_getbuf: 32768 bytes atapi: 1 DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x08073550 size: 36 - using copy buffer DMA addr: 0xBFFFDDC0 size: 8 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0xBFFFDAA0 size: 2 - using copy buffer DMA addr: 0xBFFFDAA0 size: 30 - using copy buffer DMA addr: 0xBFFFDBE0 size: 30 - using copy buffer Device type: Removable CD-ROM Version: 0 Response Format: 1 Vendor_info: 'HP ' Identifikation : 'CD-Writer+ 7100 ' Revision : '3.01' Device seems to be: Generic mmc CD-RW. DMA addr: 0xBFFFDF40 size: 8 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0xBFFFDC20 size: 2 - using copy buffer DMA addr: 0xBFFFDC20 size: 30 - using copy buffer DMA addr: 0xBFFFDD60 size: 30 - using copy buffer DMA addr: 0xBFFFDF60 size: 8 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0xBFFFDC40 size: 2 - using copy buffer DMA addr: 0xBFFFDC40 size: 30 - using copy buffer DMA addr: 0xBFFFDD80 size: 30 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0xBFFFDD70 size: 2 - using copy buffer DMA addr: 0xBFFFDD70 size: 30 - using copy buffer DMA addr: 0xBFFFDEB0 size: 30 - using copy buffer Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : SWABAUDIO DMA addr: 0xBFFFE1B0 size: 12 - using copy buffer Drive buf size : 786432 = 768 KB ./cdrecord: Input/output error. read toc: scsi sendcmd: retryable error status: 0x2 (CHECK CONDITION) DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0xBFFFDF30 size: 259 - using copy buffer Pages: 0x1 0x5 0xd 0xe 0x2a DMA addr: 0x size: 0 - using copy buffer DMA addr: 0xBFFFDF30 size: 259 - using copy buffer Pages: 0x1 0x5 0xd 0xe 0x2a Current Secsize: -1 DMA addr: 0x08073578 size: 8 - using copy buffer DMA addr: 0xBFFFE0C0 size: 2 - using copy buffer Disk info: 00 20 10 01 01 01 01 00 00 00 00 00 00 00 00 00 00 61 1A 3F 00 4B 00 00 00 00 00 00 00 00 00 00 00 00 Disk info: 00 20 10 01 01 01 01 00 00 00 00 00 00 00 00 00 00 61 1A 3F 00 4B
Re: failure to blank CDRWs (2.2.18pre15 smp ide-scsi hp7100i)
On Mon, 16 Oct 2000, Andre Hedrick wrote: > Yes but there is a way to do this directly now, the question is can the > user-space apps change to go both ways. Hi Andre, Is there any tool / test code that you know of to 'do this directly' - I'm wanting to try to avoid ade-scsi translation, and show the drive's still working okay for blanking. One less variable in the soup to worry about then. Aside: Browsing through the cdrecord 10a4 source does flag a specific note in the mmc driver about ATIP not being supported on the 7100, but seems to suggest that a failure to read the ATIP data's non-fatal... Mark -- +-+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: failure to blank CDRWs (2.2.18pre15 smp ide-scsi hp7100i)
On Mon, 16 Oct 2000, Ricky Beam wrote: > There are specific notes about the HP 7100 drives not working corectly due > to bad command translations. That was supposed to have been fixed years > ago. Hi Ricky, And I know it was working on this very machine some time in the past with a 2.2.x. Where are you seeing these notes ? Only refs to the 7100 I can see are for patching in atapi support into 2.0.x :) (quick poke around the doc directory in the rh7 cdrecord-1.9 package / looking at the web site) Where did you see this noted ? I have the latest HP firmware (3.01) loaded on the 7100i, so the notes wrt firmware 2.02 I found on http://www.fadden.com/cdrfaq/faq05.html#[5-1-5] hopefully got resolved. *source for the very latest cdrecord alpha (10a4) is just downloading* Mark -- +-----+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: failure to blank CDRWs (2.2.18pre15 smp ide-scsi hp7100i)
Hi Jeff, Alan, Jens, Thank you all for the replies. I guess I'll try to contact appropriate people at HP / try newer/older versions of cdrecord. I do know the drive was working with 2.2. a long time back. It's just rare I use the burner. One other thing that may be relevent - the HP doesn't support ATIP, whereas the Ricoh does. Speculation: cdrecord asks for ATIP, then used some default/random buffer contents, and this causes the HP to give up. Cheers, Mark > Mark Cooke wrote: > > > > Just to follow up on an earlier message / thread. I've updated to > > 2.2.18pre15 on the machine (dual celeron, gigabyte 6bxd) I was having > > trouble writing CDRWs to, and it has made no difference, > > unfortunately. > > > > With the same tools / os on my other cdrw equipped machine > > (k7/up/ricoh 9060) the very same CDRW will blank perfectly happily. -- +-----+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: failure to blank CDRWs (2.2.18pre15 smp ide-scsi hp7100i)
On Mon, 16 Oct 2000, Ricky Beam wrote: snip There are specific notes about the HP 7100 drives not working corectly due to bad command translations. That was supposed to have been fixed years ago. Hi Ricky, And I know it was working on this very machine some time in the past with a 2.2.x. Where are you seeing these notes ? Only refs to the 7100 I can see are for patching in atapi support into 2.0.x :) (quick poke around the doc directory in the rh7 cdrecord-1.9 package / looking at the web site) Where did you see this noted ? I have the latest HP firmware (3.01) loaded on the 7100i, so the notes wrt firmware 2.02 I found on http://www.fadden.com/cdrfaq/faq05.html#[5-1-5] hopefully got resolved. *source for the very latest cdrecord alpha (10a4) is just downloading* Mark -- +-+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: failure to blank CDRWs (2.2.18pre15 smp ide-scsi hp7100i)
On Mon, 16 Oct 2000, Andre Hedrick wrote: Yes but there is a way to do this directly now, the question is can the user-space apps change to go both ways. Hi Andre, Is there any tool / test code that you know of to 'do this directly' - I'm wanting to try to avoid ade-scsi translation, and show the drive's still working okay for blanking. One less variable in the soup to worry about then. Aside: Browsing through the cdrecord 10a4 source does flag a specific note in the mmc driver about ATIP not being supported on the 7100, but seems to suggest that a failure to read the ATIP data's non-fatal... Mark -- +-+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: failure to blank CDRWs (2.2.18pre15 smp ide-scsi hp7100i)
On Mon, 16 Oct 2000, Douglas Gilbert wrote: snip Sg has an ioctl called SG_SET_TRANSFORM which is only relevant to the ide-scsi driver. As far as I know, no applications use it. Still it is not clear why Mark's system would work on a UP machine but fail on a SMP box. Hi Douglas, Jörg, all, Background for Jörg: my hp7100i fails to blank cdrw's with cdrecord 1.8.1. A ricoh 9060 on a machine running identical kernel build / cdrecord binary works fine I just finished compiling cdrecord-1.8.1 with debug enabled. The two attached log files are from the hp7100i / smp / 2.2.18pre15, and the ricoh 9060 / up /2.2.18pre15. Exact same cdrw media. # ./cdrecord -debug dev=1,0,0 blank=all 21 | tee log.(hp7100|ricoh) I should note that the ricoh when blanking took a whole 5-6 seconds, so it didn't blank the whole disk. I guess it's being 'clever' and knew the disk was blank, and just 'made sure'. I just finished writing a 650Mb iso to the cdrw in question, so it does appear to still be okay. Looking at the traces and where they diverge it does appear to be shortly after cdrecord attempts to read ATIP data - which the Ricoh supports, and the HP7100i doesn't. I'm guessing that it's something in cdrecord making a bad assumption if ATIP isn't available, though I'll have to look further into this. Thanks to everyone who has taken time looking at this so far. It's appreciated. Cheers, Mark -- +-+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ fs: 4194304 buflen: 4198400 ./cdrecord: shared memory segment allocated: 48169 ./cdrecord: shared memory segment attached: 40149000 buf: 40149000 bufend: 4054A000, buflen: 4198400 buf: 40149000 bufend: 4054A000, buflen: 4198400 (align 0) SCSI buffer size: 32768 dev: 1,0,0 speed: -1 fs: -1 Cdrecord 1.8.1 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling TOC Type: 1 = CD-ROM scsidev: '1,0,0' scsibus: 1 target: 0 lun: 0 l1: 0xA05 l2: 0x0 Bus: 0 Target: 5 Lun: 0 Chan: 0 Ino: 10 l1: 0x3200 l2: 0x0 Bus: 1 Target: 0 Lun: 0 Chan: 0 Ino: 50 Using libscg version 'schily-0.1' scsi_getbuf: 32768 bytes atapi: 1 DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x08073550 size: 36 - using copy buffer DMA addr: 0xBFFFDDC0 size: 8 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0xBFFFDAA0 size: 2 - using copy buffer DMA addr: 0xBFFFDAA0 size: 30 - using copy buffer DMA addr: 0xBFFFDBE0 size: 30 - using copy buffer Device type: Removable CD-ROM Version: 0 Response Format: 1 Vendor_info: 'HP ' Identifikation : 'CD-Writer+ 7100 ' Revision : '3.01' Device seems to be: Generic mmc CD-RW. DMA addr: 0xBFFFDF40 size: 8 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0xBFFFDC20 size: 2 - using copy buffer DMA addr: 0xBFFFDC20 size: 30 - using copy buffer DMA addr: 0xBFFFDD60 size: 30 - using copy buffer DMA addr: 0xBFFFDF60 size: 8 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0xBFFFDC40 size: 2 - using copy buffer DMA addr: 0xBFFFDC40 size: 30 - using copy buffer DMA addr: 0xBFFFDD80 size: 30 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0xBFFFDD70 size: 2 - using copy buffer DMA addr: 0xBFFFDD70 size: 30 - using copy buffer DMA addr: 0xBFFFDEB0 size: 30 - using copy buffer Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : SWABAUDIO DMA addr: 0xBFFFE1B0 size: 12 - using copy buffer Drive buf size : 786432 = 768 KB ./cdrecord: Input/output error. read toc: scsi sendcmd: retryable error status: 0x2 (CHECK CONDITION) DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0x size: 0 - using copy buffer DMA addr: 0xBFFFDF30 size: 259 - using copy buffer Pages: 0x1 0x5 0xd 0xe 0x2a DMA addr: 0x size: 0 - using copy buffer DMA addr: 0xBFFFDF30 size: 259 - using copy buffer Pages: 0x1 0x5 0xd 0xe 0x2a Current Secsize: -1 DMA addr: 0x08073578 size: 8 - using copy buffer DMA addr: 0xBFFFE0C0 size: 2 - using copy buffer Disk info: 00 20 10 01 01 01 01 00 00 00 00 00 00 00
failure to blank CDRWs (2.2.18pre15 smp ide-scsi hp7100i)
Hi all, Just to follow up on an earlier message / thread. I've updated to 2.2.18pre15 on the machine (dual celeron, gigabyte 6bxd) I was having trouble writing CDRWs to, and it has made no difference, unfortunately. With the same tools / os on my other cdrw equipped machine (k7/up/ricoh 9060) the very same CDRW will blank perfectly happily. Both machines have the CDRW as the sole device on the second ide-chain. Using xcdrgtk's blank cd option which uses cdrecord 1.8.1 on the failed machine gives the following log. Using speed=1 or spped=2 makes no difference to the error reported. Cdrecord 1.8.1 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling TOC Type: 1 = CD-ROM scsidev: '1,0,0' scsibus: 1 target: 0 lun: 0 Using libscg version 'schily-0.1' atapi: 1 Device type: Removable CD-ROM Version: 0 Response Format: 1 Vendor_info: 'HP ' Identifikation : 'CD-Writer+ 7100 ' Revision : '3.01' Device seems to be: Generic mmc CD-RW. Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : SWABAUDIO Drive buf size : 786432 = 768 KB Current Secsize: 2048 ATIP start of lead in: -11637 (97:26/63) ATIP start of lead out: 337350 (75:00/00) Disk type: phase change Manuf. index: 3 Manufacturer: CMC Magnetics Corporation Blocks total: 337350 Blocks current: 337350 Blocks remaining: 337500 Starting to write CD/DVD at speed 2 in write mode for single session. Blanking entire disk CDB: A1 00 00 00 00 00 00 00 00 00 00 00 cdrecord: Input/output error. blank unit: scsi sendcmd: retryable error Sense Bytes: F0 00 05 00 00 00 00 19 00 02 89 16 A1 10 00 80 status: 0x2 (CHECK CONDITION) Sense Key: 0x5 Illegal Request, Segment 0 cdrecord: Cannot blank disk, aborting. Sense Code: 0xA1 Qual 0x10 (vendor unique sense code 0xA1) [No matching qualifier] Fru 0x0 Sense flags: Blk 0 (valid) error refers to data part, bit ptr 0 (not valid) field ptr 0 cmd finished after 13.218s timeout 9600s Anyone have any ideas? Mark -- +-+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
failure to blank CDRWs (2.2.18pre15 smp ide-scsi hp7100i)
Hi all, Just to follow up on an earlier message / thread. I've updated to 2.2.18pre15 on the machine (dual celeron, gigabyte 6bxd) I was having trouble writing CDRWs to, and it has made no difference, unfortunately. With the same tools / os on my other cdrw equipped machine (k7/up/ricoh 9060) the very same CDRW will blank perfectly happily. Both machines have the CDRW as the sole device on the second ide-chain. Using xcdrgtk's blank cd option which uses cdrecord 1.8.1 on the failed machine gives the following log. Using speed=1 or spped=2 makes no difference to the error reported. Cdrecord 1.8.1 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling TOC Type: 1 = CD-ROM scsidev: '1,0,0' scsibus: 1 target: 0 lun: 0 Using libscg version 'schily-0.1' atapi: 1 Device type: Removable CD-ROM Version: 0 Response Format: 1 Vendor_info: 'HP ' Identifikation : 'CD-Writer+ 7100 ' Revision : '3.01' Device seems to be: Generic mmc CD-RW. Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : SWABAUDIO Drive buf size : 786432 = 768 KB Current Secsize: 2048 ATIP start of lead in: -11637 (97:26/63) ATIP start of lead out: 337350 (75:00/00) Disk type: phase change Manuf. index: 3 Manufacturer: CMC Magnetics Corporation Blocks total: 337350 Blocks current: 337350 Blocks remaining: 337500 Starting to write CD/DVD at speed 2 in write mode for single session. Blanking entire disk CDB: A1 00 00 00 00 00 00 00 00 00 00 00 cdrecord: Input/output error. blank unit: scsi sendcmd: retryable error Sense Bytes: F0 00 05 00 00 00 00 19 00 02 89 16 A1 10 00 80 status: 0x2 (CHECK CONDITION) Sense Key: 0x5 Illegal Request, Segment 0 cdrecord: Cannot blank disk, aborting. Sense Code: 0xA1 Qual 0x10 (vendor unique sense code 0xA1) [No matching qualifier] Fru 0x0 Sense flags: Blk 0 (valid) error refers to data part, bit ptr 0 (not valid) field ptr 0 cmd finished after 13.218s timeout 9600s Anyone have any ideas? Mark -- +-+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: BTTV Driver under 2.2.18preX bug
On Sun, 24 Sep 2000, Alan Cox wrote:
> Im waiting for someone to either explain why the changes should have caused
> the problem and to fix them.
>
> Right now I dont see what is going on so Im not changing anything until I
> understand what is up
Hi Alan,
Summary: outdated vidmem override causes problems because of a change
to bttv_open to call find_vga correctly the first time the device is
openned.
Details: (written as I rambled through the problem)
I've looked at the diff between 2.2.17 and 2.2.18pre9 wrt bttv.c, and
the only thing that looks possibly a cause is that the fix to
bttv_open to actually call find_vga when the device is openned is
exposing a bug / problem with the video memory base selection with my
graphics card. (Geforce 256)
*checks some more* Okay, found a problem with my installation here -
I have upgraded graphics cards from a TNT/2 to the Geforce and not
changed the vidmem override setting. *sigh*
The change in pre9 must expose this somehow - in a way that 17 final
didn't. Ie, actually calling find_vga puts a non-zero value into the
vidadr member of the win struct, and this enables various ioctls with
what was an incorrect override address - hence getting blank windows
and crashes.
Putting the right value into vidmem has fixed the problem here. I'm
just test compiling with a patch adding the Creative Labs Geforce 256
to the vidbases table in bttv.c, which will at least fix the logged
message from bttv that it can't find the graphics card, and obviate
the need for me to specify the vidmem manually...(though it doesn't
help for owners of other video cards).
bttv: PCI display adapter: <3>bttv: Unknown video memory base address.
01:00.0 VGA compatible controller: nVidia Corporation: Unknown device
0100 (rev 10) (prog-if 00 [VGA])
Subsystem: Creative Labs: Unknown device 102d
Flags: bus master, 66Mhz, medium devsel, latency 248, IRQ 10
Memory at e000 (32-bit, non-prefetchable)
Memory at d800 (32-bit, prefetchable)
Capabilities: [60] Power Management version 1
Capabilities: [44] AGP version 2.0
01:00.0 Class 0300: 10de:0100 (rev 10)
Subsystem: 1102:102d
Flags: bus master, 66Mhz, medium devsel, latency 248, IRQ 10
Memory at e000 (32-bit, non-prefetchable)
Memory at d800 (32-bit, prefetchable)
Capabilities: [60] Power Management version 1
Capabilities: [44] AGP version 2.0
The d800 address is the video ram. I'm assuming that the vendor
id is 0x10de, and the device id 0x0100, and making a guess that
because the memory is the 2nd listed, I need PCI_BASE_ADDRESS_1 in the
table too.
I've CC'd Jens so he can add the entries to pci.h in a form he
prefers.
Best regards,
Mark
--
+-----+
Mark Cooke The views expressed above are mine and are not
Systems Programmer necessarily representative of university policy
University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/
+-+
--- linux/drivers/char/bttv.c.orig Sun Sep 24 18:56:31 2000
+++ linux/drivers/char/bttv.c Sun Sep 24 19:13:13 2000
@@ -2708,6 +2708,8 @@
{ PCI_VENDOR_ID_TSENG, 0, "TSENG", PCI_BASE_ADDRESS_0},
{ PCI_VENDOR_ID_NVIDIA_SGS, PCI_DEVICE_ID_NVIDIA_SGS_RIVA128,
"Riva128", PCI_BASE_ADDRESS_1},
+ { PCI_VENDOR_ID_NVIDIA, PCI_VENDOR_ID_NVIDIA_GEFORCE256,
+"GeForce 256", PCI_BASE_ADDRESS_1},
};
--- linux/include/linux/pci.h.orig Fri Sep 22 01:34:44 2000
+++ linux/include/linux/pci.h Sun Sep 24 19:11:51 2000
@@ -732,6 +732,7 @@
#define PCI_DEVICE_ID_CERN_HIPPI_SRC 0x0022
#define PCI_VENDOR_ID_NVIDIA 0x10de
+#define PCI_VENDOR_ID_NVIDIA_GEFORCE2560x0100
#define PCI_VENDOR_ID_IMS 0x10e0
#define PCI_DEVICE_ID_IMS_8849 0x8849
Re: BTTV Driver under 2.2.18preX bug
On Sun, 24 Sep 2000, Alan Cox wrote:
Im waiting for someone to either explain why the changes should have caused
the problem and to fix them.
Right now I dont see what is going on so Im not changing anything until I
understand what is up
Hi Alan,
Summary: outdated vidmem override causes problems because of a change
to bttv_open to call find_vga correctly the first time the device is
openned.
Details: (written as I rambled through the problem)
I've looked at the diff between 2.2.17 and 2.2.18pre9 wrt bttv.c, and
the only thing that looks possibly a cause is that the fix to
bttv_open to actually call find_vga when the device is openned is
exposing a bug / problem with the video memory base selection with my
graphics card. (Geforce 256)
*checks some more* Okay, found a problem with my installation here -
I have upgraded graphics cards from a TNT/2 to the Geforce and not
changed the vidmem override setting. *sigh*
The change in pre9 must expose this somehow - in a way that 17 final
didn't. Ie, actually calling find_vga puts a non-zero value into the
vidadr member of the win struct, and this enables various ioctls with
what was an incorrect override address - hence getting blank windows
and crashes.
Putting the right value into vidmem has fixed the problem here. I'm
just test compiling with a patch adding the Creative Labs Geforce 256
to the vidbases table in bttv.c, which will at least fix the logged
message from bttv that it can't find the graphics card, and obviate
the need for me to specify the vidmem manually...(though it doesn't
help for owners of other video cards).
bttv: PCI display adapter: 3bttv: Unknown video memory base address.
01:00.0 VGA compatible controller: nVidia Corporation: Unknown device
0100 (rev 10) (prog-if 00 [VGA])
Subsystem: Creative Labs: Unknown device 102d
Flags: bus master, 66Mhz, medium devsel, latency 248, IRQ 10
Memory at e000 (32-bit, non-prefetchable)
Memory at d800 (32-bit, prefetchable)
Capabilities: [60] Power Management version 1
Capabilities: [44] AGP version 2.0
01:00.0 Class 0300: 10de:0100 (rev 10)
Subsystem: 1102:102d
Flags: bus master, 66Mhz, medium devsel, latency 248, IRQ 10
Memory at e000 (32-bit, non-prefetchable)
Memory at d800 (32-bit, prefetchable)
Capabilities: [60] Power Management version 1
Capabilities: [44] AGP version 2.0
The d800 address is the video ram. I'm assuming that the vendor
id is 0x10de, and the device id 0x0100, and making a guess that
because the memory is the 2nd listed, I need PCI_BASE_ADDRESS_1 in the
table too.
I've CC'd Jens so he can add the entries to pci.h in a form he
prefers.
Best regards,
Mark
--
+-+
Mark Cooke The views expressed above are mine and are not
Systems Programmer necessarily representative of university policy
University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/
+-+
--- linux/drivers/char/bttv.c.orig Sun Sep 24 18:56:31 2000
+++ linux/drivers/char/bttv.c Sun Sep 24 19:13:13 2000
@@ -2708,6 +2708,8 @@
{ PCI_VENDOR_ID_TSENG, 0, "TSENG", PCI_BASE_ADDRESS_0},
{ PCI_VENDOR_ID_NVIDIA_SGS, PCI_DEVICE_ID_NVIDIA_SGS_RIVA128,
"Riva128", PCI_BASE_ADDRESS_1},
+ { PCI_VENDOR_ID_NVIDIA, PCI_VENDOR_ID_NVIDIA_GEFORCE256,
+"GeForce 256", PCI_BASE_ADDRESS_1},
};
--- linux/include/linux/pci.h.orig Fri Sep 22 01:34:44 2000
+++ linux/include/linux/pci.h Sun Sep 24 19:11:51 2000
@@ -732,6 +732,7 @@
#define PCI_DEVICE_ID_CERN_HIPPI_SRC 0x0022
#define PCI_VENDOR_ID_NVIDIA 0x10de
+#define PCI_VENDOR_ID_NVIDIA_GEFORCE2560x0100
#define PCI_VENDOR_ID_IMS 0x10e0
#define PCI_DEVICE_ID_IMS_8849 0x8849
Re: BTTV Driver under 2.2.18preX bug
On Sun, 24 Sep 2000 [EMAIL PROTECTED] wrote: > Anybody else encountered a bug with the bttv driver under kernel > 2.2.18preX (All the Pre-releases) ? > Or the other thing- anybody got bttv driver to work under these kernels ? > > When I'm using this kernel with 2.2.17 bttv.o , it works great.. Hiya, Using xawtv 3.19 with 2.2.18pre9 doesn't appear to work correctly here either. It was working fine with 2.2.17pre20. Haven't tried any other of the 2.2.18pre series as I only just got finished with repackaging my kernel rpm not to include usb/nfs patches. v4l-conf is reporting that the base address disagrees between v4l and dga during xawtv startup. Not sure if this was the case with 2.2.17, as I start xawtv from the gnome panel usually (no terminal window). xawtv was certainly in overlay mode when I was running 2.2.17pre20. WARNING: v4l and dga disagree about the framebuffer base WARNING: Is v4l-conf installed correctly? ov_fbuf.base=0xe100, base=0xd800 WARNING: overlay mode disabled I hadn't reported yet because I'm using the NVidia binary module (0.95, recompiled against 2.2.18pre9 headers), and wanted to try to isolate the problem specifically to some change in pre9, and not something in the NVidia module for XFree 4.01 not liking something else in pre9 (like the agp stuff). Trying various -nodga/-noxv/-novm flags to xawtv produces an interesting array of hard locks and xawtv crashing. I'll try a 2.2.18pre9 with the 2.2.17 bttv.c/h tomorrow morning. Regards, Mark +-----+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: BTTV Driver under 2.2.18preX bug
On Sun, 24 Sep 2000 [EMAIL PROTECTED] wrote: Anybody else encountered a bug with the bttv driver under kernel 2.2.18preX (All the Pre-releases) ? Or the other thing- anybody got bttv driver to work under these kernels ? When I'm using this kernel with 2.2.17 bttv.o , it works great.. Hiya, Using xawtv 3.19 with 2.2.18pre9 doesn't appear to work correctly here either. It was working fine with 2.2.17pre20. Haven't tried any other of the 2.2.18pre series as I only just got finished with repackaging my kernel rpm not to include usb/nfs patches. v4l-conf is reporting that the base address disagrees between v4l and dga during xawtv startup. Not sure if this was the case with 2.2.17, as I start xawtv from the gnome panel usually (no terminal window). xawtv was certainly in overlay mode when I was running 2.2.17pre20. WARNING: v4l and dga disagree about the framebuffer base WARNING: Is v4l-conf installed correctly? ov_fbuf.base=0xe100, base=0xd800 WARNING: overlay mode disabled I hadn't reported yet because I'm using the NVidia binary module (0.95, recompiled against 2.2.18pre9 headers), and wanted to try to isolate the problem specifically to some change in pre9, and not something in the NVidia module for XFree 4.01 not liking something else in pre9 (like the agp stuff). Trying various -nodga/-noxv/-novm flags to xawtv produces an interesting array of hard locks and xawtv crashing. I'll try a 2.2.18pre9 with the 2.2.17 bttv.c/h tomorrow morning. Regards, Mark +-+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
