* CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] @ 2006-01-27 16:37 Bartlomiej Zolnierkiewicz 2006-01-29 11:01 ` Joerg Schilling 2006-02-10 17:58 ` CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] Marc Koschewski 0 siblings, 2 replies; 89+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2006-01-27 16:37 UTC (permalink / raw) To: Joerg Schilling; +Cc: mrmacman_g4, matthias.andree, linux-kernel, acahalan Hi, I'm stealing thread in hope of stopping flamewar and finally having some useful discussion. I address this to everybody not only to Joerg: [*] As this is my thread now discussing SG_IO on /dev/hd* vs /dev/sg* is BANNED. Please continue discussing this in the old thread. :-) I'm sure thare are other important things that we can agree on. If it doesn't work it will be my first and the last mail in this thread... On 1/27/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > Vojtech Pavlik <vojtech@suse.cz> wrote: > > > > The only integrative (and this useful for libscg) interface on Linux is /dev/sg* > > > > > > /dev/hd* may look nice if you only look skin-deep > > > > > > How do you e.g. like send SCSI commands to ATAPI tape drives on Linux? > > > > I see you asking this again and again, and you seem to want to hear this > > answer: "You don't." I haven't checked the code, but I guess the SG_IO > > interface isn't available there. And I don't think this is a problem, > > because a) if it was needed, it can be added trivially with minimum > > added code, b) ATAPI tapes are dead, much the way ATAPI floppies are. > > Nice to see that agree that sending SCSI via /dev/hd* is a hack with limited > benefit. > > Maybe (now that we did agree about the way to go) it makes sense to start > discussing which bugs in Linux need to be fixed in order to close e.g. > the Bugs in the Debian bug tracking system for cdrtools that are related to the > Linux kernel. Yes, lets talk about other problems, do you have pointers bugs handy? I'm not very familiar with Debian bug tracking system and I see there more than 3 bugs for cdrtools. > This are the three most important Linux kernel bugs: > > - ide-scsi does not do DMA if the DMAsize is not a multiple of 512 > A person who knows internal Linux structures shoule be able > to fix this (and allow any multiple of 4) in less than one hour. I'll take a look, it should be quite easy and I don't see a reason for this restriction. > If we sum up the time spend on this discussoion, I really cannot > understand why this has not been fixed earlier. Because nobody cared and flamewaring is easy in contrast to doing some real work. > - /dev/hd* artificially prevents the ioctls SCSI_IOCTL_GET_IDLUN > SCSI_IOCTL_GET_BUS_NUMBER from returning useful values. > As long as this bug is present, there is no way to see SG_IO > via /dev/hd* as integral part of the Linux SCSI transport concept. What are the return values of SCSI_IOCTL_GET_IDLUN and SCSI_IOCTL_GET_BUS_NUMBER needed for? Please elaborate as: * SG_IO ioctl doesn't require lun and bus number for arguments * sg_io_hdr_t also doesn't contain/require these fields so I simply cannot see why they are needed by kernel. If lun and bus number are needed by cdrecord please explain why (if only for enumerating devices sorry but see [*]). > - If sending SCSI sia ATAPI, Linux under certain unknown conditions > bastardizes the content of SCSI commands. A possible reason may be Sorry but I can't do much about it without knowing more details. Please provide some way to reproduce the problem ("certain unknown conditions" is not very useful). > that it sends random data in the remainder between the actual > SCSI cdb size and the ATAPI SCSI cdb size. It should send 0-s but I'll recheck this. > ATAPI drives that verify SCSI cdb's for correctness fail in this > case. Thanks, Bartlomiej ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-27 16:37 CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] Bartlomiej Zolnierkiewicz @ 2006-01-29 11:01 ` Joerg Schilling 2006-01-29 11:15 ` Jan Engelhardt ` (2 more replies) 2006-02-10 17:58 ` CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] Marc Koschewski 1 sibling, 3 replies; 89+ messages in thread From: Joerg Schilling @ 2006-01-29 11:01 UTC (permalink / raw) To: schilling, bzolnier; +Cc: mrmacman_g4, matthias.andree, linux-kernel, acahalan Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote: > I address this to everybody not only to Joerg: > > [*] As this is my thread now discussing SG_IO on /dev/hd* vs /dev/sg* > is BANNED. Please continue discussing this in the old thread. :-) If we also bann discussions that try to claim cdrecord -scanbus is unneeded or unwanted, no problem. > > Maybe (now that we did agree about the way to go) it makes sense to start > > discussing which bugs in Linux need to be fixed in order to close e.g. > > the Bugs in the Debian bug tracking system for cdrtools that are related to the > > Linux kernel. > > Yes, lets talk about other problems, do you have pointers bugs handy? > I'm not very familiar with Debian bug tracking system and I see there > more than 3 bugs for cdrtools. There unfortunately are many "Bugs" on Debian. Most of the "Bugs" are either realls Linux bugs or just caused by the modifications done by the Debian people. You would need to read the reports and it makes sense to look for comments from me. > > This are the three most important Linux kernel bugs: > > > > - ide-scsi does not do DMA if the DMAsize is not a multiple of 512 > > A person who knows internal Linux structures shoule be able > > to fix this (and allow any multiple of 4) in less than one hour. > > I'll take a look, it should be quite easy > and I don't see a reason for this restriction. Testing could be done the following way: - insert a blank CD into your writer and do an initial test burn. sdd -inull bs=2352 of= test.raw count=75x60x74 cdrecord dev=ATA:b,t,0 -audio -sao -v test.raw Remember the speed that should be > 40x Remember the system cpu time that should be less than 5% of the wall clock time. - Repeat the same test with ide-scsi Make sure ide-scsi is usable fo the drive, then call cdrecord dev=b,t,0 -audio -sao -v test.raw If the max speed is lower than 30x or the system cpu time ich significant more than 5% of the wall closk time you do not use DMA. > > If we sum up the time spend on this discussoion, I really cannot > > understand why this has not been fixed earlier. > > Because nobody cared and flamewaring is easy in contrast > to doing some real work. > > > - /dev/hd* artificially prevents the ioctls SCSI_IOCTL_GET_IDLUN > > SCSI_IOCTL_GET_BUS_NUMBER from returning useful values. > > As long as this bug is present, there is no way to see SG_IO > > via /dev/hd* as integral part of the Linux SCSI transport concept. > > What are the return values of SCSI_IOCTL_GET_IDLUN > and SCSI_IOCTL_GET_BUS_NUMBER needed for? > > Please elaborate as: > > * SG_IO ioctl doesn't require lun and bus number for arguments > * sg_io_hdr_t also doesn't contain/require these fields > > so I simply cannot see why they are needed by kernel. > > If lun and bus number are needed by cdrecord please explain why > (if only for enumerating devices sorry but see [*]). Well it is obvious that the numbers are present inside Linux, otherwise Linux could not return useful numbers in case that ide-scsi is used. Note that we are talking about SCSI devices (in case the actual user of libscg is cdrecord, we talk about CD/DVD writers). If you read the Debian bug reports, you will find that many users are confused because cdrecord -scanbus will not list all possible devices. > > - If sending SCSI sia ATAPI, Linux under certain unknown conditions > > bastardizes the content of SCSI commands. A possible reason may be > > Sorry but I can't do much about it without knowing more details. I am sorry, but as nobody was interested on this when it was possible to tell more it did has been fogotten. > Please provide some way to reproduce the problem > ("certain unknown conditions" is not very useful). Well if I remember correclty, then the problem does not occur in case you use a Plextor drive. It may IIRC make sense to try to reproduce with Pioneer or NEC drives. I believe the best way to allow to reproduce the problem would be to search the web or the Debian bugtracking for related error reports. Unfortunately Debian seems to be down. "invalid field in cdb" is the related error code from the drive and this is most likely a result of this bug: http://lists.debian.org/debian-user-german/2003/10/msg00058.html I made the experience with 'Read Full Toc' and "readcd" while trying to do a clone read. But this is something you will most likely not be able to find on the web as the related error is hidden because this is not a mandatory command in SCSI. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-29 11:01 ` Joerg Schilling @ 2006-01-29 11:15 ` Jan Engelhardt 2006-01-29 11:28 ` Matthias Andree 2006-01-30 15:24 ` Joerg Schilling 2006-01-29 11:26 ` Matthias Andree 2006-01-31 1:43 ` Patrick McFarland 2 siblings, 2 replies; 89+ messages in thread From: Jan Engelhardt @ 2006-01-29 11:15 UTC (permalink / raw) To: Joerg Schilling Cc: bzolnier, mrmacman_g4, matthias.andree, linux-kernel, acahalan >Testing could be done the following way: > >- insert a blank CD into your writer and do an initial test burn. > > sdd -inull bs=2352 of= test.raw count=75x60x74 > cdrecord dev=ATA:b,t,0 -audio -sao -v test.raw > > Remember the speed that should be > 40x Does speed==40 also suffice? How about a DVD at 8x speed? (Even faster than CD at 40x) Jan Engelhardt -- | Software Engineer and Linux/Unix Network Administrator | Alphagate Systems, http://alphagate.hopto.org/ | jengelh's site, http://jengelh.hopto.org/ ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-29 11:15 ` Jan Engelhardt @ 2006-01-29 11:28 ` Matthias Andree 2006-01-30 15:24 ` Joerg Schilling 1 sibling, 0 replies; 89+ messages in thread From: Matthias Andree @ 2006-01-29 11:28 UTC (permalink / raw) To: Jan Engelhardt Cc: Joerg Schilling, bzolnier, mrmacman_g4, matthias.andree, linux-kernel, acahalan Jan Engelhardt schrieb am 2006-01-29: > Does speed==40 also suffice? > How about a DVD at 8x speed? (Even faster than CD at 40x) The block size of 2352 bytes (not a power of two and not a multiple of 512 either) is important. Just check the CPU load. The machine is pretty crawling without DMA, with high system and I/O wait figures. Even fast machines (Athlon XP 2500+) are hogged down so much the mouse pointer gets jerky. -- Matthias Andree ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-29 11:15 ` Jan Engelhardt 2006-01-29 11:28 ` Matthias Andree @ 2006-01-30 15:24 ` Joerg Schilling 2006-02-05 12:03 ` Jan Engelhardt 1 sibling, 1 reply; 89+ messages in thread From: Joerg Schilling @ 2006-01-30 15:24 UTC (permalink / raw) To: schilling, jengelh Cc: mrmacman_g4, matthias.andree, linux-kernel, bzolnier, acahalan Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > >Testing could be done the following way: > > > >- insert a blank CD into your writer and do an initial test burn. > > > > sdd -inull bs=2352 of= test.raw count=75x60x74 > > cdrecord dev=ATA:b,t,0 -audio -sao -v test.raw > > > > Remember the speed that should be > 40x > > Does speed==40 also suffice? NO, speed==40 may be too slow as I cannot grant that it will always fail with PIO and speed <=40. In case that the clock rate of your CPU just fits nicely, it may be that it by accident works. > How about a DVD at 8x speed? (Even faster than CD at 40x) This problem is not present with DVDs as they only support virtual sector size == 2048. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-30 15:24 ` Joerg Schilling @ 2006-02-05 12:03 ` Jan Engelhardt 2006-02-06 16:29 ` Joerg Schilling 0 siblings, 1 reply; 89+ messages in thread From: Jan Engelhardt @ 2006-02-05 12:03 UTC (permalink / raw) To: Joerg Schilling Cc: mrmacman_g4, matthias.andree, linux-kernel, bzolnier, acahalan Hi, I just found that the followig "works" (cdrom drive not supported, but other than that seems fine) under Solaris 11 snv_30 x86, much to my surprise: cdrecord -dev=/dev/rdsk/c1t0d0p0 -toc which worked just as well as cdrecord -dev=1,0,0 -toc I would have rather expected to get Warning: Open by 'devname' is unintentional and not supported. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-02-05 12:03 ` Jan Engelhardt @ 2006-02-06 16:29 ` Joerg Schilling 2006-02-06 17:17 ` René Rebe 2006-02-06 18:02 ` Matthias Andree 0 siblings, 2 replies; 89+ messages in thread From: Joerg Schilling @ 2006-02-06 16:29 UTC (permalink / raw) To: schilling, jengelh Cc: mrmacman_g4, matthias.andree, linux-kernel, bzolnier, acahalan Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > I just found that the followig "works" (cdrom drive not supported, but > other than that seems fine) under Solaris 11 snv_30 x86, much to my > surprise: > > cdrecord -dev=/dev/rdsk/c1t0d0p0 -toc > > which worked just as well as > > cdrecord -dev=1,0,0 -toc > > I would have rather expected to get > > Warning: Open by 'devname' is unintentional and not supported. You are the first to try this unsupported dev parameter. Fortunately, users on Solaris usually read the man pages before doing wrong things and then it usually works.... Once I see to many people using this kind of CLI, I'll add a note. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-02-06 16:29 ` Joerg Schilling @ 2006-02-06 17:17 ` René Rebe 2006-02-06 18:02 ` Matthias Andree 1 sibling, 0 replies; 89+ messages in thread From: René Rebe @ 2006-02-06 17:17 UTC (permalink / raw) To: Joerg Schilling Cc: jengelh, mrmacman_g4, matthias.andree, linux-kernel, bzolnier, acahalan Hi, On Monday 06 February 2006 17:29, Joerg Schilling wrote: > Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > > I just found that the followig "works" (cdrom drive not supported, but > > other than that seems fine) under Solaris 11 snv_30 x86, much to my > > surprise: > > > > cdrecord -dev=/dev/rdsk/c1t0d0p0 -toc > > > > which worked just as well as > > > > cdrecord -dev=1,0,0 -toc > > > > I would have rather expected to get > > > > Warning: Open by 'devname' is unintentional and not supported. > > You are the first to try this unsupported dev parameter. > > Fortunately, users on Solaris usually read the man pages before > doing wrong things and then it usually works.... > > Once I see to many people using this kind of CLI, I'll add a note. If I would not be in Berlin as well I would ask what good drugs there are to smoke - heck - wait - there *is* over average drug dealing going along here ... You still never ever explained *why* you think specifing devices by name is so bad ... Have you patched your schillix mount, fsck.* and co to take a pseudo SCSI ID as well? Start to get that _the_ interface to devices on Unix and a-like systems are device nodes in /dev (or simillar) - not artificially made up IDs the user has to find out for the system (or add -scanbus (or what it was) to any program executed). Still if _you_ do not like that, 99.999% of the Linux users and developers _do_. So stop whining about it. PS: Yes, I run a bastarized version of cdrecord that has a whole bunch of crap patched away. Have fun, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de | http://www.t2-project.org +49 (0)30 255 897 45 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-02-06 16:29 ` Joerg Schilling 2006-02-06 17:17 ` René Rebe @ 2006-02-06 18:02 ` Matthias Andree 1 sibling, 0 replies; 89+ messages in thread From: Matthias Andree @ 2006-02-06 18:02 UTC (permalink / raw) To: Joerg Schilling; +Cc: jengelh, mrmacman_g4, linux-kernel, bzolnier, acahalan Joerg Schilling wrote: > Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: [Solaris cdrecord command] >> cdrecord -dev=/dev/rdsk/c1t0d0p0 -toc > Once I see to many people using this kind of CLI, I'll add a note. Still fighting both your users and the environment, eh? Why do you want to enforce device enumeration on your users if it isn't needed in the first place? Your motives remain totally unclear, and look rather suicidal. ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-29 11:01 ` Joerg Schilling 2006-01-29 11:15 ` Jan Engelhardt @ 2006-01-29 11:26 ` Matthias Andree 2006-01-29 20:41 ` Jan Engelhardt 2006-01-30 15:25 ` Joerg Schilling 2006-01-31 1:43 ` Patrick McFarland 2 siblings, 2 replies; 89+ messages in thread From: Matthias Andree @ 2006-01-29 11:26 UTC (permalink / raw) To: Joerg Schilling Cc: bzolnier, mrmacman_g4, matthias.andree, linux-kernel, acahalan Joerg Schilling schrieb am 2006-01-29: > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote: > > > I address this to everybody not only to Joerg: > > > > [*] As this is my thread now discussing SG_IO on /dev/hd* vs /dev/sg* > > is BANNED. Please continue discussing this in the old thread. :-) > > If we also bann discussions that try to claim cdrecord -scanbus is > unneeded or unwanted, no problem. The real issue is that the Linux kernel support for -scanbus looks different than your blueprints. Looks as though the most promising approach is to tell libscg about it, as annoying though it may be. > Well it is obvious that the numbers are present inside Linux, otherwise > Linux could not return useful numbers in case that ide-scsi is used. > Note that we are talking about SCSI devices (in case the actual user > of libscg is cdrecord, we talk about CD/DVD writers). CD/DVD writers wtih SCSI interface have nearly died out. > If you read the Debian bug reports, you will find that many users are confused > because cdrecord -scanbus will not list all possible devices. That's what I believe to be cdrecord/libscg bugs: 1) libscg or cdrecord does not automatically probe all available transports, but only SCSI: 2) libscg or cdrecord aborts ATA: scans as soon as one device probe returns EPERM, which lets devices that resmgr made accessible disappear from the list. -- Matthias Andree ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-29 11:26 ` Matthias Andree @ 2006-01-29 20:41 ` Jan Engelhardt 2006-01-29 20:50 ` Joerg Schilling 2006-01-30 15:25 ` Joerg Schilling 1 sibling, 1 reply; 89+ messages in thread From: Jan Engelhardt @ 2006-01-29 20:41 UTC (permalink / raw) To: Matthias Andree Cc: Joerg Schilling, bzolnier, mrmacman_g4, linux-kernel, acahalan >That's what I believe to be cdrecord/libscg bugs: > >1) libscg or cdrecord does not automatically probe all available > transports, but only SCSI: This one is IMO just "a missing feature", as I can get the ATA/PI list using cdrecord -dev=ATA: -scanbus Jan Engelhardt -- ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-29 20:41 ` Jan Engelhardt @ 2006-01-29 20:50 ` Joerg Schilling 2006-01-29 21:28 ` Albert Cahalan 2006-01-31 23:55 ` Bill Davidsen 0 siblings, 2 replies; 89+ messages in thread From: Joerg Schilling @ 2006-01-29 20:50 UTC (permalink / raw) To: matthias.andree, jengelh Cc: schilling, mrmacman_g4, linux-kernel, bzolnier, acahalan Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > >That's what I believe to be cdrecord/libscg bugs: > > > >1) libscg or cdrecord does not automatically probe all available > > transports, but only SCSI: > > This one is IMO just "a missing feature", as I can get the ATA/PI list using > cdrecord -dev=ATA: -scanbus It cannot be fixed unless the two first bugs from my Linux kernel bug report have been fixed. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-29 20:50 ` Joerg Schilling @ 2006-01-29 21:28 ` Albert Cahalan 2006-01-30 16:11 ` Joerg Schilling 2006-01-31 23:55 ` Bill Davidsen 1 sibling, 1 reply; 89+ messages in thread From: Albert Cahalan @ 2006-01-29 21:28 UTC (permalink / raw) To: Joerg Schilling Cc: matthias.andree, jengelh, mrmacman_g4, linux-kernel, bzolnier On 1/29/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > > >That's what I believe to be cdrecord/libscg bugs: > > > > > >1) libscg or cdrecord does not automatically probe all available > > > transports, but only SCSI: > > > > This one is IMO just "a missing feature", as I can get the ATA/PI list using > > cdrecord -dev=ATA: -scanbus > > It cannot be fixed unless the two first bugs from my Linux kernel > bug report have been fixed. Which, from an earlier email, were: > ide-scsi does not do DMA if the DMAsize is not a > multiple of 512 A person who knows internal Linux > structures shoule be able to fix this (and allow > any multiple of 4) in less than one hour. and > /dev/hd* artificially prevents the ioctls > SCSI_IOCTL_GET_IDLUN SCSI_IOCTL_GET_BUS_NUMBER from > returning useful values. As long as this bug is present, > there is no way to see SG_IO via /dev/hd* as integral > part of the Linux SCSI transport concept. Let's address the second bug first. Linux provides full bus number and LUN info for all block devices. You get it like this: struct stat sbuf; stat("/dev/hdc", &sbuf); int bus = sbuf.st_mode>>12; int target = major(sbuf.st_rdev); int lun = minor(sbuf.st_rdev); That makes as much sense as anything, and it lets you quickly find back the device by scanning /dev. As for ide-scsi, your right, it's horribly broken. We should just get rid of it. If there is anything that the normal driver is unable to do well, I'm sure you'll let us know. ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-29 21:28 ` Albert Cahalan @ 2006-01-30 16:11 ` Joerg Schilling 2006-01-30 16:31 ` Albert Cahalan 0 siblings, 1 reply; 89+ messages in thread From: Joerg Schilling @ 2006-01-30 16:11 UTC (permalink / raw) To: schilling, acahalan Cc: mrmacman_g4, matthias.andree, linux-kernel, jengelh, bzolnier Albert Cahalan <acahalan@gmail.com> wrote: > Let's address the second bug first. Linux provides full > bus number and LUN info for all block devices. You get it > like this: > > struct stat sbuf; > stat("/dev/hdc", &sbuf); > int bus = sbuf.st_mode>>12; > int target = major(sbuf.st_rdev); > int lun = minor(sbuf.st_rdev); Now tell me how to match this with information from /dev/sg* Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-30 16:11 ` Joerg Schilling @ 2006-01-30 16:31 ` Albert Cahalan 2006-01-30 16:35 ` Joerg Schilling 0 siblings, 1 reply; 89+ messages in thread From: Albert Cahalan @ 2006-01-30 16:31 UTC (permalink / raw) To: Joerg Schilling Cc: mrmacman_g4, matthias.andree, linux-kernel, jengelh, bzolnier On 1/30/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > Albert Cahalan <acahalan@gmail.com> wrote: > > > Let's address the second bug first. Linux provides full > > bus number and LUN info for all block devices. You get it > > like this: > > > > struct stat sbuf; > > stat("/dev/hdc", &sbuf); > > int bus = sbuf.st_mode>>12; > > int target = major(sbuf.st_rdev); > > int lun = minor(sbuf.st_rdev); > > Now tell me how to match this with information from /dev/sg* You do the obvious, scanning /dev to find the device file. You can map from names to numbers (like DNS does for IP) and back from numbers to names (like reverse DNS does). If you need to map from /dev/hd* to /dev/sg*, then you have found a bug. Explain what must be added to /dev/hd* so that you don't need to go messing with /dev/sg* anymore. The name /dev/hd* is not the high-level interface. It's the device name, used by both high-level and low-level interfaces. It alone is the non-kernel way to refer to the device. (inside the kernel you just get a pointer, and the dev_t assists in translation) ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-30 16:31 ` Albert Cahalan @ 2006-01-30 16:35 ` Joerg Schilling 2006-01-30 17:08 ` Matthias Andree 0 siblings, 1 reply; 89+ messages in thread From: Joerg Schilling @ 2006-01-30 16:35 UTC (permalink / raw) To: schilling, acahalan Cc: mrmacman_g4, matthias.andree, linux-kernel, jengelh, bzolnier Albert Cahalan <acahalan@gmail.com> wrote: > On 1/30/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > Albert Cahalan <acahalan@gmail.com> wrote: > > > > > Let's address the second bug first. Linux provides full > > > bus number and LUN info for all block devices. You get it > > > like this: > > > > > > struct stat sbuf; > > > stat("/dev/hdc", &sbuf); > > > int bus = sbuf.st_mode>>12; > > > int target = major(sbuf.st_rdev); > > > int lun = minor(sbuf.st_rdev); > > > > Now tell me how to match this with information from /dev/sg* > > You do the obvious, scanning /dev to find the device file. I am sorry, but you obviously did not understand the problem. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-30 16:35 ` Joerg Schilling @ 2006-01-30 17:08 ` Matthias Andree 2006-01-30 17:14 ` Joerg Schilling 0 siblings, 1 reply; 89+ messages in thread From: Matthias Andree @ 2006-01-30 17:08 UTC (permalink / raw) To: Joerg Schilling Cc: acahalan, mrmacman_g4, matthias.andree, linux-kernel, jengelh, bzolnier Joerg Schilling schrieb am 2006-01-30: > Albert Cahalan <acahalan@gmail.com> wrote: > > > On 1/30/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > > > Albert Cahalan <acahalan@gmail.com> wrote: > > > > > > > Let's address the second bug first. Linux provides full > > > > bus number and LUN info for all block devices. You get it > > > > like this: > > > > > > > > struct stat sbuf; > > > > stat("/dev/hdc", &sbuf); > > > > int bus = sbuf.st_mode>>12; > > > > int target = major(sbuf.st_rdev); > > > > int lun = minor(sbuf.st_rdev); > > > > > > Now tell me how to match this with information from /dev/sg* > > > > You do the obvious, scanning /dev to find the device file. > > I am sorry, but you obviously did not understand the problem. Stop offending people who are trying to be helpful just because they suggest different solutions than you expect. You - again - elided Albert's crucial part, which even included an offer to fix things: : If you need to map from /dev/hd* to /dev/sg*, then you have : found a bug. Explain what must be added to /dev/hd* so that : you don't need to go messing with /dev/sg* anymore. -- Matthias Andree ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-30 17:08 ` Matthias Andree @ 2006-01-30 17:14 ` Joerg Schilling 2006-01-30 17:30 ` Matthias Andree 2006-01-30 20:24 ` Phillip Susi 0 siblings, 2 replies; 89+ messages in thread From: Joerg Schilling @ 2006-01-30 17:14 UTC (permalink / raw) To: schilling, matthias.andree Cc: mrmacman_g4, matthias.andree, linux-kernel, jengelh, bzolnier, acahalan Matthias Andree <matthias.andree@gmx.de> wrote: > > > > > struct stat sbuf; > > > > > stat("/dev/hdc", &sbuf); > > > > > int bus = sbuf.st_mode>>12; > > > > > int target = major(sbuf.st_rdev); > > > > > int lun = minor(sbuf.st_rdev); > > > > > > > > Now tell me how to match this with information from /dev/sg* > > > > > > You do the obvious, scanning /dev to find the device file. > > > > I am sorry, but you obviously did not understand the problem. > > Stop offending people who are trying to be helpful just because they > suggest different solutions than you expect. You - again - elided > Albert's crucial part, which even included an offer to fix things: I am sorry to see your recent dicussion style. I was asking a question and I did get a completely useless answer as any person who has some basic know how Linux SCSI would know that doing a stat("/dev/sg*", ...) will not return anything useful. If people give useful answers, it makes sense to continue a discussion but it turns out that "joe average" on KLML replies before thinking about the problem. Let me ask again: Is there a way to get (or construct) a closed view on the namespace for all SCSI devices? And IMPORTANT: don't answer unless you have a real answer for the problem. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-30 17:14 ` Joerg Schilling @ 2006-01-30 17:30 ` Matthias Andree 2006-01-30 17:37 ` Joerg Schilling 2006-01-30 20:24 ` Phillip Susi 1 sibling, 1 reply; 89+ messages in thread From: Matthias Andree @ 2006-01-30 17:30 UTC (permalink / raw) To: Joerg Schilling Cc: matthias.andree, mrmacman_g4, linux-kernel, jengelh, bzolnier, acahalan Joerg Schilling schrieb am 2006-01-30: > Let me ask again: > > Is there a way to get (or construct) a closed view on the namespace > for all SCSI devices? Of course there is, /dev/sg*. But that is not what you're _actually_ asking - you appear to desire a unified namespace for SCSI + ATAPI + whatever, and the answer to that was /dev/*. Asking questions doesn't always turn up the answers one has expected... -- Matthias Andree ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-30 17:30 ` Matthias Andree @ 2006-01-30 17:37 ` Joerg Schilling 2006-01-30 17:49 ` Matthias Andree ` (2 more replies) 0 siblings, 3 replies; 89+ messages in thread From: Joerg Schilling @ 2006-01-30 17:37 UTC (permalink / raw) To: schilling, matthias.andree Cc: mrmacman_g4, matthias.andree, linux-kernel, jengelh, bzolnier, acahalan Matthias Andree <matthias.andree@gmx.de> wrote: > Joerg Schilling schrieb am 2006-01-30: > > > Let me ask again: > > > > Is there a way to get (or construct) a closed view on the namespace > > for all SCSI devices? > > Of course there is, /dev/sg*. > > But that is not what you're _actually_ asking - you appear to desire a > unified namespace for SCSI + ATAPI + whatever, and the answer to that > was /dev/*. I am only asking for a unique name space for all devices that talk SCSI. And please: read the SCSI Standard on t10.org to learn that ATA is just one of many possible SCSI transports. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-30 17:37 ` Joerg Schilling @ 2006-01-30 17:49 ` Matthias Andree 2006-01-30 20:22 ` James Courtier-Dutton 2006-01-31 10:17 ` Andreas Jellinghaus 2 siblings, 0 replies; 89+ messages in thread From: Matthias Andree @ 2006-01-30 17:49 UTC (permalink / raw) To: Joerg Schilling Cc: matthias.andree, mrmacman_g4, linux-kernel, jengelh, bzolnier, acahalan Joerg Schilling schrieb am 2006-01-30: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > Joerg Schilling schrieb am 2006-01-30: > > > > > Let me ask again: > > > > > > Is there a way to get (or construct) a closed view on the namespace > > > for all SCSI devices? > > > > Of course there is, /dev/sg*. > > > > But that is not what you're _actually_ asking - you appear to desire a > > unified namespace for SCSI + ATAPI + whatever, and the answer to that > > was /dev/*. > > I am only asking for a unique name space for all devices that talk SCSI. That is not the same. > And please: read the SCSI Standard on t10.org to learn that ATA is just one > of many possible SCSI transports. The t10.org front page mentions ATAPI links, and the links section leads to t13.org for ATAPI. And now? Besides that, Linux is not currently implemented to make everybody and their dog look like SPI with ID, LUN and everything, and until now you have not presented anything but phantoms (such as ATAPI tapes) to support your point why it should do that. No wonder people are losing interest in the discussion if you don't even answer questions what the current Linux interface don't give you, and you haven't seriously responded to my suggestion to simply scan all transports in libscg, for instance, "" (sg+pg), ATA:, ATAPI, RSCSI:. -- Matthias Andree ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-30 17:37 ` Joerg Schilling 2006-01-30 17:49 ` Matthias Andree @ 2006-01-30 20:22 ` James Courtier-Dutton 2006-01-31 10:17 ` Andreas Jellinghaus 2 siblings, 0 replies; 89+ messages in thread From: James Courtier-Dutton @ 2006-01-30 20:22 UTC (permalink / raw) To: Joerg Schilling Cc: matthias.andree, mrmacman_g4, linux-kernel, jengelh, bzolnier, acahalan Joerg Schilling wrote: > > I am only asking for a unique name space for all devices that talk SCSI. > Why do you need to ask this question of the operating system. Surely more suitable questions are: Where are the CD writing devices? Where is the user's preferred CD writing device? Surely you don't care if there is a scsi tape drive or scsi hard disk on the SCSI bus. Don't you only care about CD writing devices? James ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-30 17:37 ` Joerg Schilling 2006-01-30 17:49 ` Matthias Andree 2006-01-30 20:22 ` James Courtier-Dutton @ 2006-01-31 10:17 ` Andreas Jellinghaus 2 siblings, 0 replies; 89+ messages in thread From: Andreas Jellinghaus @ 2006-01-31 10:17 UTC (permalink / raw) To: linux-kernel Joerg Schilling wrote: > I am only asking for a unique name space for all devices that talk SCSI. > > And please: read the SCSI Standard on t10.org to learn that ATA is just > one of many possible SCSI transports. why do you need it? if you were fine with all cd bunners and dvd burners, you could use /dev/{cdrw,dvdrw}*. if you also want the dvd device and cd devices, have a look at /dev/cdrom* and /dev/dvd*. note: you need to sort out duplicates yourself, for example my laptop has one dvd writer and thus it shows up as cdrom, cdrw, dvd and dvdrw. the obvious answer to your question would be: there is none. as far as I understand the kernel developers, the real answer is: you application should not need that. Regards, Andreas ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-30 17:14 ` Joerg Schilling 2006-01-30 17:30 ` Matthias Andree @ 2006-01-30 20:24 ` Phillip Susi 2006-01-31 10:47 ` Joerg Schilling 1 sibling, 1 reply; 89+ messages in thread From: Phillip Susi @ 2006-01-30 20:24 UTC (permalink / raw) To: Joerg Schilling Cc: matthias.andree, mrmacman_g4, linux-kernel, jengelh, bzolnier, acahalan Joerg Schilling wrote: > I am sorry to see your recent dicussion style. > > I was asking a question and I did get a completely useless answer as > any person who has some basic know how Linux SCSI would know that > doing a stat("/dev/sg*", ...) will not return anything useful. > It certainly does return something useful, just not what you are looking for. It does not return information that allows you to cleanly build your bus:device:lun view of the world, but it does return sufficient information to enumerate and communicate with all devices in the system. Is that not sufficient to be able to implement cdrecord? If it is, then the real issue here is that you want Linux to conform to the bus:device:lun world view, which it seems many people do not wish to do. Maybe it would be more constructive if you were to make a good argument for why the bus:device:lun view is better than /dev/*, but right now it seems to me that they are just two different ways of doing the same thing, and you prefer one way while the rest of the Linux developers prefer the other. > If people give useful answers, it makes sense to continue a discussion but it > turns out that "joe average" on KLML replies before thinking about the problem. > > Let me ask again: > > Is there a way to get (or construct) a closed view on the namespace > for all SCSI devices? > > > And IMPORTANT: don't answer unless you have a real answer for the problem. > > Jörg > > ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-30 20:24 ` Phillip Susi @ 2006-01-31 10:47 ` Joerg Schilling 2006-01-31 11:22 ` Matthias Andree ` (2 more replies) 0 siblings, 3 replies; 89+ messages in thread From: Joerg Schilling @ 2006-01-31 10:47 UTC (permalink / raw) To: schilling, psusi Cc: mrmacman_g4, matthias.andree, linux-kernel, jengelh, bzolnier, acahalan Phillip Susi <psusi@cfl.rr.com> wrote: > Joerg Schilling wrote: > > I am sorry to see your recent dicussion style. > > > > I was asking a question and I did get a completely useless answer as > > any person who has some basic know how Linux SCSI would know that > > doing a stat("/dev/sg*", ...) will not return anything useful. > > > > It certainly does return something useful, just not what you are looking > for. It does not return information that allows you to cleanly build > your bus:device:lun view of the world, but it does return sufficient > information to enumerate and communicate with all devices in the > system. Is that not sufficient to be able to implement cdrecord? If it > is, then the real issue here is that you want Linux to conform to the > bus:device:lun world view, which it seems many people do not wish to do. It does not allow libscg to find all devices. > Maybe it would be more constructive if you were to make a good argument > for why the bus:device:lun view is better than /dev/*, but right now it > seems to me that they are just two different ways of doing the same > thing, and you prefer one way while the rest of the Linux developers > prefer the other. It would help if someone would give arguments why Linux does treat all SCSI devices equal, except for ATAPI transport based ones. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-31 10:47 ` Joerg Schilling @ 2006-01-31 11:22 ` Matthias Andree 2006-02-01 0:15 ` Bill Davidsen 2006-02-01 7:45 ` Tejun Heo 2 siblings, 0 replies; 89+ messages in thread From: Matthias Andree @ 2006-01-31 11:22 UTC (permalink / raw) To: Joerg Schilling Cc: psusi, mrmacman_g4, matthias.andree, linux-kernel, jengelh, bzolnier, acahalan Joerg Schilling schrieb am 2006-01-31: > > It certainly does return something useful, just not what you are looking > > for. It does not return information that allows you to cleanly build > > your bus:device:lun view of the world, but it does return sufficient > > information to enumerate and communicate with all devices in the > > system. Is that not sufficient to be able to implement cdrecord? If it > > is, then the real issue here is that you want Linux to conform to the > > bus:device:lun world view, which it seems many people do not wish to do. > > It does not allow libscg to find all devices. On my system, sudo cdrecord -scanbus ; \ sudo cdrecord -scanbus dev=ATA: finds all devices that talk ATAPI, SCSI, MMC. > > Maybe it would be more constructive if you were to make a good argument > > for why the bus:device:lun view is better than /dev/*, but right now it > > seems to me that they are just two different ways of doing the same > > thing, and you prefer one way while the rest of the Linux developers > > prefer the other. > > It would help if someone would give arguments why Linux does treat all > SCSI devices equal, except for ATAPI transport based ones. 1a The question is rather, what is the reason that you claim libscg is allegedly unable to find all devices? 1b Not scanning all of the devices perhaps? 1c Not asking the right enumeration interface perhaps? 2 And what devices are actually missing? Name tangible devices or groups, not phantoms that no-one uses. 3 Why does libscg need to care at all which kernel driver provides SG_IO? The device node give access to the target the user desires. Add serial number listing to -scanbus to make those happy that have several drives of the same brand and model. 4 Why have you not yet responded to the suggestion to use freedesktop.org HAL to enumerate devices? Summarizing past discussions, it appears as though you have not presented sufficiently substantiated arguments to prove libscg is actually missing out on device, and not sufficient evidence to convince kernel developers to CHANGE things. The same way as you want them to justify their using device nodes instead bus:id:lun to map everything into a narrow namespace, they can make you justify your request. Fact is that cdrecord+libscg appear to work well enough so that nobody wants to care about theoretical gaps that have no practical impact. And given that libscg's namespace is already transport:bus:id:lun which comprises /dev/hd* and /dev/sg* so nicely that CD writing works today, it seems hard to justify changes beyond 1. removing irritating warnings from cdrecord/libscg, 2. making libscg actually scan all transports and not just one when looking for devices. It is pretty clear now that the Linux kernel developers do not care if your application bitches at users because you don't like a particular interface. -- Matthias Andree ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-31 10:47 ` Joerg Schilling 2006-01-31 11:22 ` Matthias Andree @ 2006-02-01 0:15 ` Bill Davidsen 2006-02-01 7:45 ` Tejun Heo 2 siblings, 0 replies; 89+ messages in thread From: Bill Davidsen @ 2006-02-01 0:15 UTC (permalink / raw) To: Joerg Schilling Cc: mrmacman_g4, matthias.andree, linux-kernel, jengelh, bzolnier, acahalan Joerg Schilling wrote: > Phillip Susi <psusi@cfl.rr.com> wrote: > > >>Joerg Schilling wrote: >> >>>I am sorry to see your recent dicussion style. >>> >>>I was asking a question and I did get a completely useless answer as >>>any person who has some basic know how Linux SCSI would know that >>>doing a stat("/dev/sg*", ...) will not return anything useful. >>> >> >>It certainly does return something useful, just not what you are looking >>for. It does not return information that allows you to cleanly build >>your bus:device:lun view of the world, but it does return sufficient >>information to enumerate and communicate with all devices in the >>system. Is that not sufficient to be able to implement cdrecord? If it >>is, then the real issue here is that you want Linux to conform to the >>bus:device:lun world view, which it seems many people do not wish to do. > > > It does not allow libscg to find all devices. > > >>Maybe it would be more constructive if you were to make a good argument >>for why the bus:device:lun view is better than /dev/*, but right now it >>seems to me that they are just two different ways of doing the same >>thing, and you prefer one way while the rest of the Linux developers >>prefer the other. > > > It would help if someone would give arguments why Linux does treat all > SCSI devices equal, except for ATAPI transport based ones. That's a fair question, which I asked in a seperate thread. Everything in the system which looks like a block device, tape or optical device looks like SCSI except ATAPI. However, as my mother used to say "those are the conditions which prevail," so perhaps it's time to accept it and move on. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-31 10:47 ` Joerg Schilling 2006-01-31 11:22 ` Matthias Andree 2006-02-01 0:15 ` Bill Davidsen @ 2006-02-01 7:45 ` Tejun Heo 2006-02-01 16:41 ` Joerg Schilling 2 siblings, 1 reply; 89+ messages in thread From: Tejun Heo @ 2006-02-01 7:45 UTC (permalink / raw) To: Joerg Schilling Cc: psusi, mrmacman_g4, matthias.andree, linux-kernel, jengelh, bzolnier, acahalan Joerg Schilling wrote: > Phillip Susi <psusi@cfl.rr.com> wrote: > > >>Joerg Schilling wrote: >> >>>I am sorry to see your recent dicussion style. >>> >>>I was asking a question and I did get a completely useless answer as >>>any person who has some basic know how Linux SCSI would know that >>>doing a stat("/dev/sg*", ...) will not return anything useful. >>> >> >>It certainly does return something useful, just not what you are looking >>for. It does not return information that allows you to cleanly build >>your bus:device:lun view of the world, but it does return sufficient >>information to enumerate and communicate with all devices in the >>system. Is that not sufficient to be able to implement cdrecord? If it >>is, then the real issue here is that you want Linux to conform to the >>bus:device:lun world view, which it seems many people do not wish to do. > > It does not allow libscg to find all devices. > >>Maybe it would be more constructive if you were to make a good argument >>for why the bus:device:lun view is better than /dev/*, but right now it >>seems to me that they are just two different ways of doing the same >>thing, and you prefer one way while the rest of the Linux developers >>prefer the other. > > It would help if someone would give arguments why Linux does treat all > SCSI devices equal, except for ATAPI transport based ones. > Mostly historic, I guess. When IDE drivers first got implemented, ATAPI wasn't really considered thoroughly and later when generic SCSI command support became necessary it was added by bridging ATAPI devices over to SCSI using ide-scsi. People didn't like ide-scsi very much for good reasons - special boot parameter, confusing, needed full SCSI stack etc... So, the hd SG_IO came. And, yes, hd SG_IO has certain drawbacks as you pointed out. No generic command to tape device (as no generic IDE device exists), not an integral part of SCSI subsystem and might even contain some new bugs as it's different new (well, was) code base. Yet, people in general seem to find the change more beneficial and I personally like the change too. ide-scsi is obsolete now. Going back to it just won't happen and as I just said, yeah, some good stuff was lost in the process but others are gained, so please accept it - there is no central repository of SCSI command aware devices on Linux, at least at the moment. It might happen in time but *currently* there is none. I also think it would be better to have one but, hey, that's how the current state is and it will take quite some amount of work and time to implement that correctly. So, let's meet somewhere inbetween. Reserving a SCSI bus number for ATAPI devices and generating ID/LUN for SG_IO devices isn't very difficult and probably a good thing to have. So, unfortunately, we won't have pretty /dev/sg* for all SCSI-aware devices, but you only have to scan limited number of devices - /dev/sg* and /dev/hd*. How does that sound? -- tejun ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-02-01 7:45 ` Tejun Heo @ 2006-02-01 16:41 ` Joerg Schilling 0 siblings, 0 replies; 89+ messages in thread From: Joerg Schilling @ 2006-02-01 16:41 UTC (permalink / raw) To: schilling, htejun Cc: psusi, mrmacman_g4, matthias.andree, linux-kernel, jengelh, bzolnier, acahalan Tejun Heo <htejun@gmail.com> wrote: > So, let's meet somewhere inbetween. Reserving a SCSI bus number for > ATAPI devices and generating ID/LUN for SG_IO devices isn't very > difficult and probably a good thing to have. So, unfortunately, we > won't have pretty /dev/sg* for all SCSI-aware devices, but you only have > to scan limited number of devices - /dev/sg* and /dev/hd*. libscg already has to deal with this kind of problems (see /dev/pg*). You can't add work arounds ad nauseum. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-29 20:50 ` Joerg Schilling 2006-01-29 21:28 ` Albert Cahalan @ 2006-01-31 23:55 ` Bill Davidsen 2006-02-01 15:06 ` Joerg Schilling 1 sibling, 1 reply; 89+ messages in thread From: Bill Davidsen @ 2006-01-31 23:55 UTC (permalink / raw) To: Joerg Schilling; +Cc: mrmacman_g4, linux-kernel, bzolnier, acahalan Joerg Schilling wrote: > Jan Engelhardt <jengelh@linux01.gwdg.de> wrote: > > >>>That's what I believe to be cdrecord/libscg bugs: >>> >>>1) libscg or cdrecord does not automatically probe all available >>> transports, but only SCSI: >> >>This one is IMO just "a missing feature", as I can get the ATA/PI list using >> cdrecord -dev=ATA: -scanbus > > > It cannot be fixed unless the two first bugs from my Linux kernel > bug report have been fixed. Since we are making an effort to be civil, perhaps you might call these "characteristics" instead of bugs. Generally "bug" refers to an unintended behaviour, rather than an intended behaviour which may not be optimal. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-31 23:55 ` Bill Davidsen @ 2006-02-01 15:06 ` Joerg Schilling 0 siblings, 0 replies; 89+ messages in thread From: Joerg Schilling @ 2006-02-01 15:06 UTC (permalink / raw) To: schilling, davidsen; +Cc: mrmacman_g4, linux-kernel, bzolnier, acahalan Bill Davidsen <davidsen@tmr.com> wrote: > Since we are making an effort to be civil, perhaps you might call these > "characteristics" instead of bugs. Generally "bug" refers to an > unintended behaviour, rather than an intended behaviour which may not be > optimal. If you are talking about the DMA problem, this should be calle a bug as the same problem has been fixed elsewhere. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-29 11:26 ` Matthias Andree 2006-01-29 20:41 ` Jan Engelhardt @ 2006-01-30 15:25 ` Joerg Schilling 2006-01-30 17:09 ` Matthias Andree 1 sibling, 1 reply; 89+ messages in thread From: Joerg Schilling @ 2006-01-30 15:25 UTC (permalink / raw) To: schilling, matthias.andree Cc: mrmacman_g4, matthias.andree, linux-kernel, bzolnier, acahalan Matthias Andree <matthias.andree@gmx.de> wrote: > 2) libscg or cdrecord aborts ATA: scans as soon as one device probe > returns EPERM, which lets devices that resmgr made accessible > disappear from the list. looks like your memory does not last long enough...... We did already discuss this before. If you call cdrecord with apropriatr privileges, it works. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-30 15:25 ` Joerg Schilling @ 2006-01-30 17:09 ` Matthias Andree 2006-01-30 17:15 ` Joerg Schilling 0 siblings, 1 reply; 89+ messages in thread From: Matthias Andree @ 2006-01-30 17:09 UTC (permalink / raw) To: Joerg Schilling Cc: matthias.andree, mrmacman_g4, linux-kernel, bzolnier, acahalan Joerg Schilling schrieb am 2006-01-30: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > 2) libscg or cdrecord aborts ATA: scans as soon as one device probe > > returns EPERM, which lets devices that resmgr made accessible > > disappear from the list. > > looks like your memory does not last long enough...... > > We did already discuss this before. If you call cdrecord with > apropriatr privileges, it works. Well, if you're freezing the bugs, I don't see how there could be progress towards a non-root cdrecord on Linux. -- Matthias Andree ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-30 17:09 ` Matthias Andree @ 2006-01-30 17:15 ` Joerg Schilling 2006-01-30 23:26 ` Pavel Machek 0 siblings, 1 reply; 89+ messages in thread From: Joerg Schilling @ 2006-01-30 17:15 UTC (permalink / raw) To: schilling, matthias.andree Cc: mrmacman_g4, matthias.andree, linux-kernel, bzolnier, acahalan Matthias Andree <matthias.andree@gmx.de> wrote: > > > 2) libscg or cdrecord aborts ATA: scans as soon as one device probe > > > returns EPERM, which lets devices that resmgr made accessible > > > disappear from the list. > > > > looks like your memory does not last long enough...... > > > > We did already discuss this before. If you call cdrecord with > > apropriatr privileges, it works. > > Well, if you're freezing the bugs, I don't see how there could be > progress towards a non-root cdrecord on Linux. There is no such bug in libscg. There is nothing that has been freezed. If you have the apropriate privs to send SCSI commands to any SCSI device on the system, you will not come across your problem. Now let us try to talk about real problems or stop this discussion. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-30 17:15 ` Joerg Schilling @ 2006-01-30 23:26 ` Pavel Machek 2006-02-01 15:51 ` Jan Engelhardt 0 siblings, 1 reply; 89+ messages in thread From: Pavel Machek @ 2006-01-30 23:26 UTC (permalink / raw) To: Joerg Schilling Cc: matthias.andree, mrmacman_g4, linux-kernel, bzolnier, acahalan On Po 30-01-06 18:15:49, Joerg Schilling wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > > > 2) libscg or cdrecord aborts ATA: scans as soon as one device probe > > > > returns EPERM, which lets devices that resmgr made accessible > > > > disappear from the list. > > > > > > looks like your memory does not last long enough...... > > > > > > We did already discuss this before. If you call cdrecord with > > > apropriatr privileges, it works. > > > > Well, if you're freezing the bugs, I don't see how there could be > > progress towards a non-root cdrecord on Linux. > > There is no such bug in libscg. > > There is nothing that has been freezed. > > If you have the apropriate privs to send SCSI commands to any SCSI device > on the system, you will not come across your problem. Why should I need privs to talk to *any* SCSI device, when I want to talk to just *one* SCSI device? Yes, it is a missing feature in libscg. It requires priviledge to talk to *any* device, while is only really needs to talk to *one* device. [Imagine ls that only worked if it had priviledges for reading /etc/shadow. That would surely be bug.] Pavel -- Thanks, Sharp! ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-30 23:26 ` Pavel Machek @ 2006-02-01 15:51 ` Jan Engelhardt 0 siblings, 0 replies; 89+ messages in thread From: Jan Engelhardt @ 2006-02-01 15:51 UTC (permalink / raw) To: Pavel Machek Cc: Joerg Schilling, matthias.andree, mrmacman_g4, linux-kernel, bzolnier, acahalan >> >> If you have the apropriate privs to send SCSI commands to any SCSI device >> on the system, you will not come across your problem. > >Why should I need privs to talk to *any* SCSI device, when I want to >talk to just *one* SCSI device? > Because of the (drumroll...) -scanbus thing everyone wants! Jan Engelhardt -- ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-29 11:01 ` Joerg Schilling 2006-01-29 11:15 ` Jan Engelhardt 2006-01-29 11:26 ` Matthias Andree @ 2006-01-31 1:43 ` Patrick McFarland 2006-01-31 1:47 ` CD writing in future Linux try #2 David S. Miller ` (3 more replies) 2 siblings, 4 replies; 89+ messages in thread From: Patrick McFarland @ 2006-01-31 1:43 UTC (permalink / raw) To: Joerg Schilling Cc: bzolnier, mrmacman_g4, matthias.andree, linux-kernel, acahalan On Sunday 29 January 2006 06:01, Joerg Schilling wrote: > Danger: Highly Flammable Material. <!> I formally request that Joerg Schilling be banned from the LKML until he learns how to take bugs in his program seriously. cdrecord has bugs, people hit them, and he won't either fix the bugs, or hand maintainership over to someone who wants to fix them. Not only that, he constantly trolls on the LKML about how awesome cdrecord is, and how stupid kernel developers are. He also rears his head in any discussion on CD burning under Linux, even though it not always has anything to do with cdrecord; and totally derails any such discussion. In addition to the aforementioned problems, he also has a serious hate for Debian, and the Debian developers who maintain the cdrecord package; in addition, he has lesser hate for all Linux developers, users, and basically anyone who isn't using Schillix or worshipping the ground he walks on. I believe LKML is for serious discussion of Linux kernel development only, and for this to optimally continue, we need to purge the list of trolls like him. -- Patrick "Diablo-D3" McFarland || diablod3@gmail.com "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-01-31 1:43 ` Patrick McFarland @ 2006-01-31 1:47 ` David S. Miller 2006-01-31 11:13 ` Gerhard Mack 2006-01-31 14:15 ` linux-os (Dick Johnson) [not found] ` <515e525f0601302205h4a845f36u12b946515759239a@mail.gmail.com> ` (2 subsequent siblings) 3 siblings, 2 replies; 89+ messages in thread From: David S. Miller @ 2006-01-31 1:47 UTC (permalink / raw) To: diablod3 Cc: schilling, bzolnier, mrmacman_g4, matthias.andree, linux-kernel, acahalan From: Patrick McFarland <diablod3@gmail.com> Date: Mon, 30 Jan 2006 20:43:55 -0500 > I believe LKML is for serious discussion of Linux kernel development > only, and for this to optimally continue, we need to purge the list > of trolls like him. I'd rather natural forces work to show him what an anti-social person he is. We don't need to ban him from the lists, as that is an act which is about as low as he is, and we don't need to stoop like that. ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-01-31 1:47 ` CD writing in future Linux try #2 David S. Miller @ 2006-01-31 11:13 ` Gerhard Mack 2006-01-31 11:18 ` David S. Miller 2006-01-31 16:46 ` Lennart Sorensen 2006-01-31 14:15 ` linux-os (Dick Johnson) 1 sibling, 2 replies; 89+ messages in thread From: Gerhard Mack @ 2006-01-31 11:13 UTC (permalink / raw) To: David S. Miller Cc: diablod3, schilling, bzolnier, mrmacman_g4, matthias.andree, linux-kernel, acahalan On Mon, 30 Jan 2006, David S. Miller wrote: > Date: Mon, 30 Jan 2006 17:47:05 -0800 (PST) > From: David S. Miller <davem@davemloft.net> > Subject: Re: CD writing in future Linux try #2 > > From: Patrick McFarland <diablod3@gmail.com> > Date: Mon, 30 Jan 2006 20:43:55 -0500 > > > I believe LKML is for serious discussion of Linux kernel development > > only, and for this to optimally continue, we need to purge the list > > of trolls like him. > > I'd rather natural forces work to show him what an anti-social person > he is. We don't need to ban him from the lists, as that is an act > which is about as low as he is, and we don't need to stoop like that. The downside to that is that while this all gets fought out cd burning on Linux is more of a pain than it should be. Gerhard -- Gerhard Mack gmack@innerfire.net <>< As a computer I find your faith in technology amusing. ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-01-31 11:13 ` Gerhard Mack @ 2006-01-31 11:18 ` David S. Miller 2006-02-01 0:28 ` Bill Davidsen 2006-02-01 4:49 ` Albert Cahalan 2006-01-31 16:46 ` Lennart Sorensen 1 sibling, 2 replies; 89+ messages in thread From: David S. Miller @ 2006-01-31 11:18 UTC (permalink / raw) To: gmack Cc: diablod3, schilling, bzolnier, mrmacman_g4, matthias.andree, linux-kernel, acahalan From: Gerhard Mack <gmack@innerfire.net> Date: Tue, 31 Jan 2006 06:13:09 -0500 (EST) > The downside to that is that while this all gets fought out cd burning on > Linux is more of a pain than it should be. Someone remind me why the whole world is a prisoner to Joerg's cd burning program? Anybody can write their own, and if Joerg is a pain to work with that is a double extra incentive for this other implementation to be written. In fact I'm very surprised this hasn't happened already. ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-01-31 11:18 ` David S. Miller @ 2006-02-01 0:28 ` Bill Davidsen 2006-02-01 15:12 ` Joerg Schilling 2006-02-02 16:29 ` Jan Engelhardt 2006-02-01 4:49 ` Albert Cahalan 1 sibling, 2 replies; 89+ messages in thread From: Bill Davidsen @ 2006-02-01 0:28 UTC (permalink / raw) To: David S. Miller Cc: diablod3, schilling, bzolnier, mrmacman_g4, matthias.andree, linux-kernel, acahalan David S. Miller wrote: > From: Gerhard Mack <gmack@innerfire.net> > Date: Tue, 31 Jan 2006 06:13:09 -0500 (EST) > > >>The downside to that is that while this all gets fought out cd burning on >>Linux is more of a pain than it should be. > > > Someone remind me why the whole world is a prisoner to Joerg's cd > burning program? > > Anybody can write their own, and if Joerg is a pain to work with that > is a double extra incentive for this other implementation to be > written. > > In fact I'm very surprised this hasn't happened already. Because Jorg has maintained the program for a decade, has found and supported new vendors and devices, he seems to get new hardware sooner than most, and many programs and scripts use his program as an output stage. Unless someone wants to dedicate themselves to do such a program things will go the way of certain other programs which were "the best" before they were obsolete. There's a reason why the list is called cdwrite, and no one uses that any more. Joerg is technically astute, and has no clue how to interface with people without pissing them off. He loves the obsolete sg interface, he thinks his DVD-pro thing will make money but the last time I checked he didn't tke credit cards or paypal, and he just has no people skills or interest in learning them. That's why people put up with him, he continues to support what he does. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-01 0:28 ` Bill Davidsen @ 2006-02-01 15:12 ` Joerg Schilling 2006-02-01 15:25 ` Matthias Andree 2006-02-02 16:29 ` Jan Engelhardt 1 sibling, 1 reply; 89+ messages in thread From: Joerg Schilling @ 2006-02-01 15:12 UTC (permalink / raw) To: davidsen, davem Cc: schilling, mrmacman_g4, matthias.andree, linux-kernel, diablod3, bzolnier, acahalan Bill Davidsen <davidsen@tmr.com> wrote: > Joerg is technically astute, and has no clue how to interface with > people without pissing them off. He loves the obsolete sg interface, he > thinks his DVD-pro thing will make money but the last time I checked he > didn't tke credit cards or paypal, and he just has no people skills or > interest in learning them. How did you manage to write 3 incorrect claims inside a single sentence? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-01 15:12 ` Joerg Schilling @ 2006-02-01 15:25 ` Matthias Andree 2006-02-01 16:32 ` Joerg Schilling 2006-02-02 16:24 ` Jan Engelhardt 0 siblings, 2 replies; 89+ messages in thread From: Matthias Andree @ 2006-02-01 15:25 UTC (permalink / raw) To: Joerg Schilling; +Cc: davidsen, linux-kernel Joerg Schilling schrieb am 2006-02-01: > Bill Davidsen <davidsen@tmr.com> wrote: > > > Joerg is technically astute, and has no clue how to interface with > > people without pissing them off. He loves the obsolete sg interface, he > > thinks his DVD-pro thing will make money but the last time I checked he > > didn't tke credit cards or paypal, and he just has no people skills or > > interest in learning them. > > How did you manage to write 3 incorrect claims inside a single sentence? You don't consider yourself astute or being skilled in working with people? That's news to me. (Hint: list the statements you think are false). -- Matthias Andree ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-01 15:25 ` Matthias Andree @ 2006-02-01 16:32 ` Joerg Schilling 2006-02-02 16:24 ` Jan Engelhardt 1 sibling, 0 replies; 89+ messages in thread From: Joerg Schilling @ 2006-02-01 16:32 UTC (permalink / raw) To: schilling, linux-kernel; +Cc: linux-kernel, davidsen Matthias Andree <matthias.andree@gmx.de> wrote: > Joerg Schilling schrieb am 2006-02-01: > > > Bill Davidsen <davidsen@tmr.com> wrote: > > > > > Joerg is technically astute, and has no clue how to interface with > > > people without pissing them off. He loves the obsolete sg interface, he > > > thinks his DVD-pro thing will make money but the last time I checked he > > > didn't tke credit cards or paypal, and he just has no people skills or > > > interest in learning them. > > > > How did you manage to write 3 incorrect claims inside a single sentence? > > You don't consider yourself astute or being skilled in working with > people? That's news to me. (Hint: list the statements you think are false). The way a reply is made depends on what it is going to reply to. This was a reply to a really offensive mail..... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-01 15:25 ` Matthias Andree 2006-02-01 16:32 ` Joerg Schilling @ 2006-02-02 16:24 ` Jan Engelhardt 1 sibling, 0 replies; 89+ messages in thread From: Jan Engelhardt @ 2006-02-02 16:24 UTC (permalink / raw) To: linux-kernel; +Cc: Joerg Schilling, davidsen >> > Joerg is technically astute, and has no clue how to interface with >> > people without pissing them off. He loves the obsolete sg interface, he >> > thinks his DVD-pro thing will make money but the last time I checked he >> > didn't tke credit cards or paypal, and he just has no people skills or >> > interest in learning them. >> >> How did you manage to write 3 incorrect claims inside a single sentence? > >You don't consider yourself astute or being skilled in working with >people? That's news to me. (Hint: list the statements you think are false). > 17:26 shanghai:~ > grep astute /usr/share/dict/de-en.txt Scharfsinnigkeit {f}; Scharfsinn {m} :: astuteness scharfsinnig {adj} :: astute scharfsinnig {adv} :: astutely HTH. This word might be perceived (at least I do) in two different ways in German. Jan Engelhardt -- | Software Engineer and Linux/Unix Network Administrator | Alphagate Systems, http://alphagate.hopto.org/ | jengelh's site, http://jengelh.hopto.org/ ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-01 0:28 ` Bill Davidsen 2006-02-01 15:12 ` Joerg Schilling @ 2006-02-02 16:29 ` Jan Engelhardt 2006-02-02 18:37 ` Bill Davidsen 1 sibling, 1 reply; 89+ messages in thread From: Jan Engelhardt @ 2006-02-02 16:29 UTC (permalink / raw) To: Bill Davidsen Cc: David S. Miller, diablod3, schilling, bzolnier, mrmacman_g4, matthias.andree, linux-kernel, acahalan >> >> Someone remind me why the whole world is a prisoner to Joerg's cd >> burning program? >> >> Anybody can write their own, and if Joerg is a pain to work with that >> is a double extra incentive for this other implementation to be >> written. >> >> In fact I'm very surprised this hasn't happened already. > > Because Jorg has maintained the program for a decade, has found and supported > new vendors and devices, he seems to get new hardware sooner than most, and > many programs and scripts use his program as an output stage. > Because cdrecord (and recently -prodvd) work. And they are "somewhat free". There are not much dvd-dl writing programs around that do it without crashing freezing or foobaring the disc. You are right, I could go to Nero or Nero4Linux ("the best of burning from Windows now for Linux"), but I don't. > he thinks his > DVD-pro thing will make money but the last time I checked he didn't tke credit > cards or paypal The last time I checked, prodvd was free for non-commercial purposes and - as far as I can *guess* - is free for commercial purposes as long as they give notice that it is being used. Unless commercials disguise using the non-commercial key. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-02 16:29 ` Jan Engelhardt @ 2006-02-02 18:37 ` Bill Davidsen 2006-02-03 12:58 ` Joerg Schilling 0 siblings, 1 reply; 89+ messages in thread From: Bill Davidsen @ 2006-02-02 18:37 UTC (permalink / raw) To: Jan Engelhardt Cc: schilling, bzolnier, matthias.andree, linux-kernel, acahalan Jan Engelhardt wrote: >>>Someone remind me why the whole world is a prisoner to Joerg's cd >>>burning program? >>> >>>Anybody can write their own, and if Joerg is a pain to work with that >>>is a double extra incentive for this other implementation to be >>>written. >>> >>>In fact I'm very surprised this hasn't happened already. >> >>Because Jorg has maintained the program for a decade, has found and supported >>new vendors and devices, he seems to get new hardware sooner than most, and >>many programs and scripts use his program as an output stage. >> > > > Because cdrecord (and recently -prodvd) work. And they are "somewhat free". > There are not much dvd-dl writing programs around that do it without crashing > freezing or foobaring the disc. You are right, I could go to Nero or Nero4Linux > ("the best of burning from Windows now for Linux"), but I don't. > > >>he thinks his >>DVD-pro thing will make money but the last time I checked he didn't tke credit >>cards or paypal > > > The last time I checked, prodvd was free for non-commercial purposes and - as > far as I can *guess* - is free for commercial purposes as long as they give > notice that it is being used. Unless commercials disguise using the > non-commercial key. Free, but not open source, and that's an issue with a mission critical application. For home use it doesn't matter, for business use it really does. Only one person has the source, and he could be hit by a bus like anyone else. Or if he uses as much tact in person as he does in email, he might become unavailable at any moment. I wasn't complaining about the price of ProDVD, just noting that when it first came out I tried to buy a license and found that Paypal wasn't an option. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-02 18:37 ` Bill Davidsen @ 2006-02-03 12:58 ` Joerg Schilling 2006-02-03 13:15 ` Matthias Andree ` (2 more replies) 0 siblings, 3 replies; 89+ messages in thread From: Joerg Schilling @ 2006-02-03 12:58 UTC (permalink / raw) To: jengelh, davidsen Cc: schilling, matthias.andree, linux-kernel, bzolnier, acahalan Bill Davidsen <davidsen@tmr.com> wrote: > Free, but not open source, and that's an issue with a mission critical > application. For home use it doesn't matter, for business use it really Since when is mission critical requiring OpenSource? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-03 12:58 ` Joerg Schilling @ 2006-02-03 13:15 ` Matthias Andree 2006-02-03 16:43 ` Joerg Schilling 2006-02-03 13:30 ` linux-os (Dick Johnson) 2006-02-03 19:27 ` Bill Davidsen 2 siblings, 1 reply; 89+ messages in thread From: Matthias Andree @ 2006-02-03 13:15 UTC (permalink / raw) To: Joerg Schilling; +Cc: linux-kernel Joerg Schilling schrieb am 2006-02-03: > Bill Davidsen <davidsen@tmr.com> wrote: > > > Free, but not open source, and that's an issue with a mission critical > > application. For home use it doesn't matter, for business use it really > > Since when is mission critical requiring OpenSource? Now this is really offensive. Bill stated the reason, yet you jump at him before even reading his message through the end. No wonder no-one's talking to you. -- Matthias Andree ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-03 13:15 ` Matthias Andree @ 2006-02-03 16:43 ` Joerg Schilling 0 siblings, 0 replies; 89+ messages in thread From: Joerg Schilling @ 2006-02-03 16:43 UTC (permalink / raw) To: schilling, matthias.andree; +Cc: linux-kernel Matthias Andree <matthias.andree@gmx.de> wrote: > Joerg Schilling schrieb am 2006-02-03: > > > Bill Davidsen <davidsen@tmr.com> wrote: > > > > > Free, but not open source, and that's an issue with a mission critical > > > application. For home use it doesn't matter, for business use it really > > > > Since when is mission critical requiring OpenSource? > > Now this is really offensive. Bill stated the reason, yet you jump at > him before even reading his message through the end. It would really help it you try to understand first.... Today many companies buy closed source software from small companies that may just disappear one day. So where is your point? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-03 12:58 ` Joerg Schilling 2006-02-03 13:15 ` Matthias Andree @ 2006-02-03 13:30 ` linux-os (Dick Johnson) 2006-02-03 19:27 ` Bill Davidsen 2 siblings, 0 replies; 89+ messages in thread From: linux-os (Dick Johnson) @ 2006-02-03 13:30 UTC (permalink / raw) To: Joerg Schilling Cc: jengelh, davidsen, matthias.andree, linux-kernel, bzolnier, acahalan On Fri, 3 Feb 2006, Joerg Schilling wrote: > Bill Davidsen <davidsen@tmr.com> wrote: > >> Free, but not open source, and that's an issue with a mission critical >> application. For home use it doesn't matter, for business use it really > > Since when is mission critical requiring OpenSource? > > Jörg > Funny, when I was returning from Austin Texas with a stop at Dallas, the B777 encountered a problem with the 1st officer's flight-director display so the airplane was delayed while the maintenance crew replaced a LRU. I watched as it was started up, "booted". It was Windows CE! Now, that's "mission critical!" Cheers, Dick Johnson Penguin : Linux version 2.6.13.4 on an i686 machine (5589.66 BogoMips). Warning : 98.36% of all statistics are fiction. _ To unsubscribe **************************************************************** The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-03 12:58 ` Joerg Schilling 2006-02-03 13:15 ` Matthias Andree 2006-02-03 13:30 ` linux-os (Dick Johnson) @ 2006-02-03 19:27 ` Bill Davidsen 2 siblings, 0 replies; 89+ messages in thread From: Bill Davidsen @ 2006-02-03 19:27 UTC (permalink / raw) To: Joerg Schilling Cc: jengelh, matthias.andree, linux-kernel, bzolnier, acahalan On Fri, 3 Feb 2006, Joerg Schilling wrote: > Bill Davidsen <davidsen@tmr.com> wrote: > > > Free, but not open source, and that's an issue with a mission critical > > application. For home use it doesn't matter, for business use it really > > Since when is mission critical requiring OpenSource? Clearly mission critical software should be available long term. Open source is one way to provide that, as is buying from a solid company. But if you were hit by a bus, who would maintain ProDVD? Not having a clear answer I would assume "no one." Open source isn't a requirement, some viable plan other than "migrate to something else" is. If good size companies are willing to put their code in escrow to release if the company is no longer supporting for some reason, it's a viable business concern. -- bill davidsen <davidsen@tmr.com> CTO TMR Associates, Inc Doing interesting things with little computers since 1979 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-01-31 11:18 ` David S. Miller 2006-02-01 0:28 ` Bill Davidsen @ 2006-02-01 4:49 ` Albert Cahalan 2006-02-01 7:56 ` jerome lacoste ` (3 more replies) 1 sibling, 4 replies; 89+ messages in thread From: Albert Cahalan @ 2006-02-01 4:49 UTC (permalink / raw) To: David S. Miller Cc: gmack, diablod3, schilling, bzolnier, mrmacman_g4, matthias.andree, linux-kernel On 1/31/06, David S. Miller <davem@davemloft.net> wrote: > Someone remind me why the whole world is a prisoner to Joerg's cd > burning program? > > Anybody can write their own, and if Joerg is a pain to work with that > is a double extra incentive for this other implementation to be > written. > > In fact I'm very surprised this hasn't happened already. It has happened, many times, but sustaining such a project is very difficult. The obstacles are numerous: All the GUI apps parse cdrecord output. The output is somehow even messier than the recent /proc/*/smaps abomination. It is thus difficult to change or replace cdrecord. One of the major GUI apps appears to be written by Joerg's real-life non-Internet friend, who naturally refuses any patches to eliminate the need for cdrecord. Joerg is a Fraunhofer employee. That gives him connections to many hardware companies. (and the RIAA, MPAA, Sony, Disney...) One may wonder if this is both blessing and curse. Forking means dealing with a giant pile of messy and ugly code. The coding conventions are... interesting... and this code has to run setuid. One had better be really careful making changes. Most people are clueless about setuid code. Starting fresh means rediscovering firmware bugs, of which there are many. Things may be getting somewhat better though, with the old pre-standard interfaces hopefully dying out. Getting the most out of the hardware will require lots of device-specific code. Joerg gets the hardware. There are all sorts of funky formats. I've only ever heard of mixed audio+data CDs for circa-1995 games and Sony spyware, but maybe there are decent people who actually create these things. In theory, somebody might be making multi-session CDs. Who knows? That all said, I just wrote /dev scan code and I'm about half way through documenting xcdroast's cdrecord expectations. I'm imagining something like this: /usr/lib/burner-helper: setuid or daemon, controlled via stdio /usr/lib/something.so: interacts with burner-helper /usr/bin/cdrecord: the crappy legacy interface /usr/bin/something: a non-crappy CLI interface (no promises) ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-01 4:49 ` Albert Cahalan @ 2006-02-01 7:56 ` jerome lacoste 2006-02-01 16:42 ` Joerg Schilling 2006-02-01 11:33 ` Rene Herman ` (2 subsequent siblings) 3 siblings, 1 reply; 89+ messages in thread From: jerome lacoste @ 2006-02-01 7:56 UTC (permalink / raw) To: Albert Cahalan Cc: David S. Miller, gmack, diablod3, schilling, bzolnier, mrmacman_g4, matthias.andree, linux-kernel On 2/1/06, Albert Cahalan <acahalan@gmail.com> wrote: > On 1/31/06, David S. Miller <davem@davemloft.net> wrote: > > > Someone remind me why the whole world is a prisoner to Joerg's cd > > burning program? > > > > Anybody can write their own, and if Joerg is a pain to work with that > > is a double extra incentive for this other implementation to be > > written. > > > > In fact I'm very surprised this hasn't happened already. > > It has happened, many times, but sustaining such a project is > very difficult. The obstacles are numerous: > > All the GUI apps parse cdrecord output. The output is somehow > even messier than the recent /proc/*/smaps abomination. It is > thus difficult to change or replace cdrecord. One of the major > GUI apps appears to be written by Joerg's real-life non-Internet > friend, who naturally refuses any patches to eliminate the need > for cdrecord. http://lists.freedesktop.org/archives/libburn/2006-January/000329.html "Announcing cdrskin, a limited cdrecord compatibility wrapper for libburn cdrskin currently is able to blank and burn data CDs with one or more tracks. [...] I am using cdrskin daily with my data backups on CD-RW where it shows about the same reliability as cdrecord-ProDVD 2.01b31. The backup success is verified by my backup tool via a MD5 stream checksum. This is the initial public release 0.1.0 of cdrskin. [...]" see also http://icculus.org/burn/ Jerome ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-01 7:56 ` jerome lacoste @ 2006-02-01 16:42 ` Joerg Schilling 2006-02-02 0:30 ` Kurt Wall 0 siblings, 1 reply; 89+ messages in thread From: Joerg Schilling @ 2006-02-01 16:42 UTC (permalink / raw) To: jerome.lacoste, acahalan Cc: schilling, mrmacman_g4, matthias.andree, linux-kernel, gmack, diablod3, davem, bzolnier jerome lacoste <jerome.lacoste@gmail.com> wrote: > http://lists.freedesktop.org/archives/libburn/2006-January/000329.html > > "Announcing cdrskin, a limited cdrecord compatibility wrapper for libburn You you really believe that something like libcdburn that does not even come close to compiling because of a syntax error in "./configure" and that is Linux only will be of any help? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-01 16:42 ` Joerg Schilling @ 2006-02-02 0:30 ` Kurt Wall 0 siblings, 0 replies; 89+ messages in thread From: Kurt Wall @ 2006-02-02 0:30 UTC (permalink / raw) To: linux-kernel On Wed, Feb 01, 2006 at 05:42:35PM +0100, Joerg Schilling took 23 lines to write: > jerome lacoste <jerome.lacoste@gmail.com> wrote: > > > http://lists.freedesktop.org/archives/libburn/2006-January/000329.html > > > > "Announcing cdrskin, a limited cdrecord compatibility wrapper for libburn > > You you really believe that something like libcdburn that does not even come > close to compiling because of a syntax error in "./configure" and that > is Linux only will be of any help? If it avoids annual pissing contests on this topic, yes. -- WHERE CAN THE MATTER BE Oh, dear, where can the matter be When it's converted to energy? There is a slight loss of parity. Johnny's so long at the fair. ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-01 4:49 ` Albert Cahalan 2006-02-01 7:56 ` jerome lacoste @ 2006-02-01 11:33 ` Rene Herman 2006-02-01 16:21 ` Jon Agirre 2006-02-02 16:35 ` Jan Engelhardt 2006-02-01 16:36 ` Joerg Schilling 2006-02-02 19:17 ` Bill Davidsen 3 siblings, 2 replies; 89+ messages in thread From: Rene Herman @ 2006-02-01 11:33 UTC (permalink / raw) To: Albert Cahalan Cc: David S. Miller, gmack, diablod3, schilling, bzolnier, mrmacman_g4, matthias.andree, linux-kernel Albert Cahalan wrote: > There are all sorts of funky formats. I've only ever heard of mixed > audio+data CDs for circa-1995 games and Sony spyware, but maybe there > are decent people who actually create these things. These are in fact very common. Lots of audio CDs, with a data bit with a few quicktime/mpeg videos. Rene. ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-01 11:33 ` Rene Herman @ 2006-02-01 16:21 ` Jon Agirre 2006-02-02 16:35 ` Jan Engelhardt 1 sibling, 0 replies; 89+ messages in thread From: Jon Agirre @ 2006-02-01 16:21 UTC (permalink / raw) To: Rene Herman Cc: Albert Cahalan, David S. Miller, gmack, diablod3, schilling, bzolnier, mrmacman_g4, matthias.andree, linux-kernel Rene Herman wrote: > Albert Cahalan wrote: > >> There are all sorts of funky formats. I've only ever heard of mixed >> audio+data CDs for circa-1995 games and Sony spyware, but maybe there >> are decent people who actually create these things. > > > These are in fact very common. Lots of audio CDs, with a data bit with > a few quicktime/mpeg videos. The MIL-CD format developed by SEGA/Yamaha for the Dreamcast is also an example of this (two sessions, audio-mode2 or mode2-mode2). We (hobbysts) use it for booting our code from normal, inexpensive CD-ROMs, instead of purchasing a GD-ROM writer or an official devkit. Best regards, Jon -- ******************************** Jon Agirre Hernández Unidad de Biofisica (CSIC-UPV/EHU) P.O.Box 644, E-48080 Bilbao, Spain. Blog: http://lostsymmetry.blogspot.com Web: http://www.ehu.es/biofisica E-mail: gbbaghej@lg.ehu.es Tel: +34 94 601 3345 Fax: +34 94 601 3360 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-01 11:33 ` Rene Herman 2006-02-01 16:21 ` Jon Agirre @ 2006-02-02 16:35 ` Jan Engelhardt 2006-02-06 23:15 ` Peter Chubb 1 sibling, 1 reply; 89+ messages in thread From: Jan Engelhardt @ 2006-02-02 16:35 UTC (permalink / raw) To: Rene Herman Cc: Albert Cahalan, David S. Miller, gmack, diablod3, schilling, bzolnier, mrmacman_g4, matthias.andree, linux-kernel > >> There are all sorts of funky formats. I've only ever heard of mixed >> audio+data CDs for circa-1995 games and Sony spyware, but maybe there >> are decent people who actually create these things. > > These are in fact very common. Lots of audio CDs, with a data bit with a few > quicktime/mpeg videos. For the record, so-called Mixed Mode discs consisting of Session 1 >> Track 1 (Data) Track 2 (Audio) Track 3 (Audio) ... exist(ed) quite a lot, when games were smaller than the audio. (Now that we have things like Doom3 and Ogg, this has sadfully turned around.) To name two of such mixedmode CDs from "popular games": Microsoft Fury3 and MechWarrior2 (Matrox Mystique W95 Edition) The other type of "mixed-mode" CDs are the so-called "CD Extra", which is: Session 1 >> Track 1 (Audio) Track 2 (Audio) ... Session 2 >> Track N (Data) from what I remember, "Music Instructor - Get freaky" was such a CD where the iso9660 track had an .mpg video clip. This was done so legacy audio players don't play all the fizzle (cat /dev/cdrom >/dev/dsp) through their speakers and damage them. (I tried in the oldest HiFi stuff I could dig up, e.g. SONY UX-1 - stayed correctly silent on Data tracks ;-) Jan Engelhardt -- ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-02 16:35 ` Jan Engelhardt @ 2006-02-06 23:15 ` Peter Chubb 2006-02-07 5:00 ` Albert Cahalan 0 siblings, 1 reply; 89+ messages in thread From: Peter Chubb @ 2006-02-06 23:15 UTC (permalink / raw) To: Jan Engelhardt Cc: Rene Herman, Albert Cahalan, David S. Miller, gmack, diablod3, schilling, bzolnier, mrmacman_g4, matthias.andree, linux-kernel >>>>> "Jan" == Jan Engelhardt <jengelh@linux01.gwdg.de> writes: >> >>> There are all sorts of funky formats. I've only ever heard of >>> mixed audio+data CDs for circa-1995 games and Sony spyware, but >>> maybe there are decent people who actually create these things. >> These are in fact very common. Lots of audio CDs, with a data bit >> with a few quicktime/mpeg videos. Jan> The other type of "mixed-mode" CDs are the so-called "CD Extra", Jan> which is: Jan> Session 1 >> Track 1 (Audio) Track 2 (Audio) ... Session 2 >> Jan> Track N (Data) I have some of these -- some Christian music publishers include sheet music (as PDFs) in an ISO FS on the second session. Published last year, so recent. Peter C ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-06 23:15 ` Peter Chubb @ 2006-02-07 5:00 ` Albert Cahalan 0 siblings, 0 replies; 89+ messages in thread From: Albert Cahalan @ 2006-02-07 5:00 UTC (permalink / raw) To: Peter Chubb Cc: Jan Engelhardt, Rene Herman, David S. Miller, gmack, diablod3, schilling, bzolnier, mrmacman_g4, matthias.andree, linux-kernel On 2/6/06, Peter Chubb <peter@chubb.wattle.id.au> wrote: > >>>>> "Jan" == Jan Engelhardt <jengelh@linux01.gwdg.de> writes: > > >> > >>> There are all sorts of funky formats. I've only ever heard of > >>> mixed audio+data CDs for circa-1995 games and Sony spyware, but > >>> maybe there are decent people who actually create these things. > >> These are in fact very common. Lots of audio CDs, with a data bit > >> with a few quicktime/mpeg videos. > > Jan> The other type of "mixed-mode" CDs are the so-called "CD Extra", > Jan> which is: > > Jan> Session 1 >> Track 1 (Audio) Track 2 (Audio) ... Session 2 >> > Jan> Track N (Data) > > > I have some of these -- some Christian music publishers include sheet > music (as PDFs) in an ISO FS on the second session. Published last > year, so recent. In other words, a cute hack in a commercial product. You're not doing this for computer backups, to play a custom mix in your car CD player, to send photos to grandma, to deliver data to a customer, or anything normal. ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-01 4:49 ` Albert Cahalan 2006-02-01 7:56 ` jerome lacoste 2006-02-01 11:33 ` Rene Herman @ 2006-02-01 16:36 ` Joerg Schilling 2006-02-01 17:01 ` Matthias Andree 2006-02-02 19:17 ` Bill Davidsen 3 siblings, 1 reply; 89+ messages in thread From: Joerg Schilling @ 2006-02-01 16:36 UTC (permalink / raw) To: davem, acahalan Cc: schilling, mrmacman_g4, matthias.andree, linux-kernel, gmack, diablod3, bzolnier Albert Cahalan <acahalan@gmail.com> wrote: > Joerg is a Fraunhofer employee. That gives him connections to > many hardware companies. (and the RIAA, MPAA, Sony, Disney...) > One may wonder if this is both blessing and curse. It is obvious that you are completely bejond reality. What is your background for writing lies like this one? How about trying to find out how reality is? > Forking means dealing with a giant pile of messy and ugly code. > The coding conventions are... interesting... and this code has > to run setuid. One had better be really careful making changes. > Most people are clueless about setuid code. The original code demonstarates that suid root is not needed if you run on an operating system that offers the needed features (e.g. Solaris). > Starting fresh means rediscovering firmware bugs, of which there > are many. Things may be getting somewhat better though, with the > old pre-standard interfaces hopefully dying out. Getting the most > out of the hardware will require lots of device-specific code. > > Joerg gets the hardware. You get the hardware if you prove that you do _real_ long time work. You constantly need to prove that you are still doing work and you need to stay in contact with the righ people. This is some kind of "social engineering" and it seems that many people from this list would have problems to do communicaton the right way..... Wheening: "someboy need to to work on this" is not doing real work. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-01 16:36 ` Joerg Schilling @ 2006-02-01 17:01 ` Matthias Andree 0 siblings, 0 replies; 89+ messages in thread From: Matthias Andree @ 2006-02-01 17:01 UTC (permalink / raw) To: Joerg Schilling; +Cc: acahalan, linux-kernel Joerg Schilling schrieb am 2006-02-01: > > Forking means dealing with a giant pile of messy and ugly code. > > The coding conventions are... interesting... and this code has > > to run setuid. One had better be really careful making changes. > > Most people are clueless about setuid code. > > The original code demonstarates that suid root is not needed > if you run on an operating system that offers the needed features (e.g. > Solaris). That's old news, no need to repost this every other hour. -- Matthias Andree ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-02-01 4:49 ` Albert Cahalan ` (2 preceding siblings ...) 2006-02-01 16:36 ` Joerg Schilling @ 2006-02-02 19:17 ` Bill Davidsen 3 siblings, 0 replies; 89+ messages in thread From: Bill Davidsen @ 2006-02-02 19:17 UTC (permalink / raw) To: Albert Cahalan Cc: gmack, diablod3, schilling, bzolnier, mrmacman_g4, matthias.andree, linux-kernel Albert Cahalan wrote: > On 1/31/06, David S. Miller <davem@davemloft.net> wrote: > > >>Someone remind me why the whole world is a prisoner to Joerg's cd >>burning program? >> >>Anybody can write their own, and if Joerg is a pain to work with that >>is a double extra incentive for this other implementation to be >>written. >> >>In fact I'm very surprised this hasn't happened already. > > > It has happened, many times, but sustaining such a project is > very difficult. The obstacles are numerous: > > All the GUI apps parse cdrecord output. The output is somehow > even messier than the recent /proc/*/smaps abomination. It is > thus difficult to change or replace cdrecord. One of the major > GUI apps appears to be written by Joerg's real-life non-Internet > friend, who naturally refuses any patches to eliminate the need > for cdrecord. > > Joerg is a Fraunhofer employee. That gives him connections to > many hardware companies. (and the RIAA, MPAA, Sony, Disney...) > One may wonder if this is both blessing and curse. > > Forking means dealing with a giant pile of messy and ugly code. > The coding conventions are... interesting... and this code has > to run setuid. One had better be really careful making changes. > Most people are clueless about setuid code. > > Starting fresh means rediscovering firmware bugs, of which there > are many. Things may be getting somewhat better though, with the > old pre-standard interfaces hopefully dying out. Getting the most > out of the hardware will require lots of device-specific code. > > Joerg gets the hardware. > > There are all sorts of funky formats. I've only ever heard of > mixed audio+data CDs for circa-1995 games and Sony spyware, but > maybe there are decent people who actually create these things. > In theory, somebody might be making multi-session CDs. Who knows? Not just in theory, I get notes from people saying they use addir for backups, which is why I wrote it, because I change ~50MB/day and one CD will hold all the change. So addir is like growisofs with some additional bells and whistles I found useful, like taking a list of files changed taoday from stdin (find) and adding them to the end of the CD, preserving or renaming directory names, etc. http://www.tmr.com/~public/source/addir if you want to see an example. I used the mixed audio and data a few times, I'm sure there are folks who use it regularly. cdrecord is full function, and continues to support new vendors and models, work around firmware bugs etc. A real replacement is going to be a lot of ongoing work. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-01-31 11:13 ` Gerhard Mack 2006-01-31 11:18 ` David S. Miller @ 2006-01-31 16:46 ` Lennart Sorensen 1 sibling, 0 replies; 89+ messages in thread From: Lennart Sorensen @ 2006-01-31 16:46 UTC (permalink / raw) To: Gerhard Mack Cc: David S. Miller, diablod3, schilling, bzolnier, mrmacman_g4, matthias.andree, linux-kernel, acahalan On Tue, Jan 31, 2006 at 06:13:09AM -0500, Gerhard Mack wrote: > The downside to that is that while this all gets fought out cd burning on > Linux is more of a pain than it should be. On the other hand, I mostly use DVDs now, and growisofs is just wonderful, and much easier to work with from the command line. Maybe someday we won't care about burning CDs anymore, or maybe growisofs will add support for it. Or maybe someone else will maintain a patch that fixes the dumb "warnings" and such in cdrecord that people can apply to it. As long as it doesn't do anything as messy as the pioneer dvd burning patch did. Len Sorensen ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 2006-01-31 1:47 ` CD writing in future Linux try #2 David S. Miller 2006-01-31 11:13 ` Gerhard Mack @ 2006-01-31 14:15 ` linux-os (Dick Johnson) 1 sibling, 0 replies; 89+ messages in thread From: linux-os (Dick Johnson) @ 2006-01-31 14:15 UTC (permalink / raw) To: David S. Miller Cc: diablod3, schilling, bzolnier, mrmacman_g4, matthias.andree, linux-kernel, acahalan On Mon, 30 Jan 2006, David S. Miller wrote: > From: Patrick McFarland <diablod3@gmail.com> > Date: Mon, 30 Jan 2006 20:43:55 -0500 > >> I believe LKML is for serious discussion of Linux kernel development >> only, and for this to optimally continue, we need to purge the list >> of trolls like him. > > I'd rather natural forces work to show him what an anti-social person > he is. We don't need to ban him from the lists, as that is an act > which is about as low as he is, and we don't need to stoop like that. > - For those who have just tuned in, I will present a bit if history. CD Writing using amateur operating systems like Windows is really quite simple for the user. Using 3rd party software, one can even access a CD/ROM as though it was a "slow" disk. CD/ROM writing is built into a lot of imaging software such as used for Kodak digital cameras. The interface to Win/2000 and higher is really quite straight-forward which may be why CD writing has found its way into a lot of such applications. Linux is a Unix variant. I/O to devices have historically been performed using open, close, read, write, and ioctl. These generic functions should remain for access to CD/ROM devices as well. If you have a CD/ROM as a SCSI device, ATA device, Firewire device, USB device, or a fiber-channel device it should be accessed just like any other block device and its name should be in /dev so one can create a sym-link, possibly /dev/cdrom or /dev/fast-CD, /dev/slow-CD, - anything the user wants. There is nothing special about a CD/ROM except that once written, you need a hacksaw to erase is. In fact, you can write the output of `tar` directly to a CD/ROM without any intervening file-system. This saves a lot of time and space when performing backups. Of course the driver requires some synchronization and, in fact, some "experimentation" to determine the power-level for a particular speed. However, those are just the details necessary to start the write process. Linux has a CD/ROM driver. It, for the most part, works okay. It was written by a person who seems to have an attitude problem. This is okay. Many smart people have such problems. One of the things this problem creates is the apparent refusal to understand by several persons, including the designer, that there are many ways to interface to a device, none better or worse than than any other. In many cases it's all about convention. The selection of the interface standard was created when Multics was stripped down and Unix ported to a PDP-7 in the seventies by Dennis Ritchie. From that time on, Unix and its variants always performed I/O using special device files for access. There isn't even anything special about these, either. It's just a method used to associate a major/minor number combination with a file-descriptor. Linux started using devices with names like fd0, fd1, etc., for floppies; hda, hdb, etc., for generic hard disks; sda, sdb, etc., for SCSI devices; scd0, scd1, etc., for SCSI CD/ROM devices ... the list goes on. When the current CD/ROM writer software was written, the writer decided to reject the historical aspects of Linux and create a device access and numbering scheme that is alien to many Unix/Linux users. It goes like this: scsibus0: 0,0,0 0) 'SEAGATE ' 'ST32171W ' '0484' Disk 0,1,0 1) 'SEAGATE ' 'ST318233LWV ' '0002' Disk 0,2,0 2) 'SEAGATE ' 'ST39102LW ' '0005' Disk 0,3,0 3) * 0,4,0 4) 'YAMAHA ' 'CRW6416S ' '1.0b' Removable CD-ROM 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * Many Linux users have complained about this for several years. The complaints have fallen upon deaf ears, which has become irksome to many. The facts are that any/all naming and numbering schemes are purely arbitrary. Internally, the kernel doesn't give a rat's ass what it was called. It's just a file-descriptor (an integer), that is associated with the device and the process using that device. It would be real nice if the designer of the software would change his interface specification so it corresponds to what the user's have become accustomed to, when dealing with Unix and its variants, or to add an additional startup interface that corresponds to the Unix/Linux convention. However, as the writer of that software, he doesn't have to change anything to placate the users. He could have designed the software so the interface uses BSD sockets if he wanted to. He just wanted to do his softare his way, and you can't blame him for that. If you want another interface, I suggest that those with such powerful opinions that they expend a lot of effort trying to put the guy down, just use a portion of that effort to write a new driver. Maybe that will free up enough time to fix some bugs. Cheers, Dick Johnson Penguin : Linux version 2.6.13.4 on an i686 machine (5589.66 BogoMips). Warning : 98.36% of all statistics are fiction. _ To unsubscribe **************************************************************** The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. ^ permalink raw reply [flat|nested] 89+ messages in thread
[parent not found: <515e525f0601302205h4a845f36u12b946515759239a@mail.gmail.com>]
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] [not found] ` <515e525f0601302205h4a845f36u12b946515759239a@mail.gmail.com> @ 2006-01-31 6:46 ` Kyle Moffett 0 siblings, 0 replies; 89+ messages in thread From: Kyle Moffett @ 2006-01-31 6:46 UTC (permalink / raw) To: Anders Karlsson Cc: Patrick McFarland, Joerg Schilling, bzolnier, matthias.andree, linux-kernel, acahalan On Jan 31, 2006, at 01:05, Anders Karlsson wrote: > On 1/31/06, Patrick McFarland <diablod3@gmail.com> wrote: >> On Sunday 29 January 2006 06:01, Joerg Schilling wrote: >>> Danger: Highly Flammable Material. <!> >> >> I formally request that Joerg Schilling be banned from the LKML >> until he learns how to take bugs in his program seriously. >> cdrecord has bugs, people hit them, and he won't either fix the >> bugs, or hand maintainership over to someone who wants to fix them. > [snip] > > Don't bother banning him, that won't fix anything. Just don't use > cdrecord and ignore his posts until he changes attitude. Anyone > with such an ego will soon notice if he/she is ignored. At least, > if he is still reading the list, he'll see the quirks and bugs > reported. It's always really easy to use a personal ban (IE: killfile). Just stick a list of email addresses somewhere and configure a mail client rule to autodelete all messages from those addresses. My list now has about a hundred addresses (including Jörg's). If they later decide to be mature/polite/etc and wish to resume discussions, they're welcome to create a new email account and start posting from there. Cheers, Kyle Moffett -- Unix was not designed to stop people from doing stupid things, because that would also stop them from doing clever things. -- Doug Gwyn ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-31 1:43 ` Patrick McFarland 2006-01-31 1:47 ` CD writing in future Linux try #2 David S. Miller [not found] ` <515e525f0601302205h4a845f36u12b946515759239a@mail.gmail.com> @ 2006-01-31 8:55 ` Pekka Enberg 2006-02-01 0:25 ` Jesper Juhl 3 siblings, 0 replies; 89+ messages in thread From: Pekka Enberg @ 2006-01-31 8:55 UTC (permalink / raw) To: Patrick McFarland Cc: Joerg Schilling, bzolnier, mrmacman_g4, matthias.andree, linux-kernel, acahalan Hi, On 1/31/06, Patrick McFarland <diablod3@gmail.com> wrote: > I formally request that Joerg Schilling be banned from the LKML until he > learns how to take bugs in his program seriously. cdrecord has bugs, people > hit them, and he won't either fix the bugs, or hand maintainership over to > someone who wants to fix them. Why bother? You can always do what I do, ignore him. Cdrecord bugs don't matter because distributors are smart enough to apply the appropiate patches. The Linux bugs Joerg has mentioned don't seem to matter to anyone except Joerg himself. You can always help the libburn people or fork cdrecord if you don't like it. Please respect the fact that Joerg has a different view of things. Even though it doesn't seem to be connected to the world the rest of us know, he is entitled to it. Perhaps now is a good time to let this thread die? Pretty please? Pekka ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-01-31 1:43 ` Patrick McFarland ` (2 preceding siblings ...) 2006-01-31 8:55 ` Pekka Enberg @ 2006-02-01 0:25 ` Jesper Juhl 2006-02-02 16:45 ` Jan Engelhardt 3 siblings, 1 reply; 89+ messages in thread From: Jesper Juhl @ 2006-02-01 0:25 UTC (permalink / raw) To: Patrick McFarland Cc: Joerg Schilling, bzolnier, mrmacman_g4, matthias.andree, linux-kernel, acahalan On 1/31/06, Patrick McFarland <diablod3@gmail.com> wrote: > On Sunday 29 January 2006 06:01, Joerg Schilling wrote: > > Danger: Highly Flammable Material. <!> > > I formally request that Joerg Schilling be banned from the LKML until he > learns how to take bugs in his program seriously. cdrecord has bugs, people > hit them, and he won't either fix the bugs, or hand maintainership over to > someone who wants to fix them. > Banning Joerg (or anyone else for that matter) from LKML doesn't solve anything. You may agree or disagree with him, but just shutting him up on LKML doesn't solve any problems. Discussion of the issue, technical points and counterpoints etc solve issues. Cencorship is never a solution, that way lies stagnation and a one-sided world view. > Not only that, he constantly trolls on the LKML about how awesome cdrecord is, > and how stupid kernel developers are. He also rears his head in any > discussion on CD burning under Linux, even though it not always has anything > to do with cdrecord; and totally derails any such discussion. > Do you have to have an app using a given feature of the kernel to be allowed to participate in a discussion? That's news to me... > In addition to the aforementioned problems, he also has a serious hate for > Debian, and the Debian developers who maintain the cdrecord package; in > addition, he has lesser hate for all Linux developers, users, and basically > anyone who isn't using Schillix or worshipping the ground he walks on. > If you can't stand a given person then add him/her to your personal killfile. The fact that a person likes or dislikes a specific group of people or a specific Linux distibution or whatever may make them obnoxious or disagreeable to you personally, but that doesn't mean that they shouldn't be allowed to express their views. You are always free to ignore Joerg if you want. > I believe LKML is for serious discussion of Linux kernel development only, and > for this to optimally continue, we need to purge the list of trolls like him. > And who's to be the judge of who's a troll and who's not? you? me? some third party? I personally agree with some things Joerg is saying and disagree with others but I still believe he should be allowed to speak, and a mail such as yours is at least as annoying/offending/trollish as anything he has said so far. If he bothers you, just ignore him. Now let's get back to a technical discussion. -- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] 2006-02-01 0:25 ` Jesper Juhl @ 2006-02-02 16:45 ` Jan Engelhardt 0 siblings, 0 replies; 89+ messages in thread From: Jan Engelhardt @ 2006-02-02 16:45 UTC (permalink / raw) To: Jesper Juhl Cc: Patrick McFarland, Joerg Schilling, bzolnier, mrmacman_g4, matthias.andree, Linux Kernel Mailing List, acahalan >> On Sunday 29 January 2006 06:01, Joerg Schilling wrote: >> > Danger: Highly Flammable Material. <!> >> >> I formally request that Joerg Schilling be banned from the LKML until he >> learns how to take bugs in his program seriously. cdrecord has bugs, people >> hit them, and he won't either fix the bugs, or hand maintainership over to >> someone who wants to fix them. >> LKML is not the Chinese Government. >> >And who's to be the judge of who's a troll and who's not? you? me? >some third party? > >I personally agree with some things Joerg is saying and disagree with >others but I still believe he should be allowed to speak, and a mail >such as yours is at least as annoying/offending/trollish as anything >he has said so far. > >If he bothers you, just ignore him. > >Now let's get back to a technical discussion. > Yep. We were quite there. At least I got that impression. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 89+ messages in thread
* CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] 2006-01-27 16:37 CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] Bartlomiej Zolnierkiewicz 2006-01-29 11:01 ` Joerg Schilling @ 2006-02-10 17:58 ` Marc Koschewski 2006-02-10 19:19 ` Phillip Susi 1 sibling, 1 reply; 89+ messages in thread From: Marc Koschewski @ 2006-02-10 17:58 UTC (permalink / raw) To: linux-kernel * Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> [2006-01-27 17:37:48 +0100]: > Hi, > > I'm stealing thread <...> ... me, too. > I address this to everybody not only to Joerg: ... me, too. I just tried blanking a CD-RW with the latest -git tree. The machine just became unresponsive and then froze. When it became unresponsive the clock in GNOME still displayed the current time but I could not focus any windows anymore. Then I had to hard reboot the machine. The logs say nothing. I repeat: nothing. Does anyone have similar problems? Marc ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] 2006-02-10 17:58 ` CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] Marc Koschewski @ 2006-02-10 19:19 ` Phillip Susi 2006-02-10 19:39 ` Gene Heskett 2006-02-10 21:00 ` Marc Koschewski 0 siblings, 2 replies; 89+ messages in thread From: Phillip Susi @ 2006-02-10 19:19 UTC (permalink / raw) To: Marc Koschewski; +Cc: linux-kernel Marc Koschewski wrote: > I just tried blanking a CD-RW with the latest -git tree. The machine just became > unresponsive and then froze. When it became unresponsive the clock in GNOME still > displayed the current time but I could not focus any windows anymore. Then I had > to hard reboot the machine. The logs say nothing. I repeat: nothing. > > Does anyone have similar problems? Instead of rebooting, just wait for the blanking to finish. My guess is that your burner and hard drive are both on the same ide channel, and so you can not access the disk while the burner is blanking. If this is the case, put each drive on their own ide channel. ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] 2006-02-10 19:19 ` Phillip Susi @ 2006-02-10 19:39 ` Gene Heskett 2006-02-10 20:12 ` Kyle Moffett 2006-02-10 21:00 ` Marc Koschewski 1 sibling, 1 reply; 89+ messages in thread From: Gene Heskett @ 2006-02-10 19:39 UTC (permalink / raw) To: linux-kernel On Friday 10 February 2006 14:19, Phillip Susi wrote: >Marc Koschewski wrote: >> I just tried blanking a CD-RW with the latest -git tree. The machine >> just became unresponsive and then froze. When it became unresponsive >> the clock in GNOME still displayed the current time but I could not >> focus any windows anymore. Then I had to hard reboot the machine. >> The logs say nothing. I repeat: nothing. >> >> Does anyone have similar problems? > >Instead of rebooting, just wait for the blanking to finish. My guess > is that your burner and hard drive are both on the same ide channel, > and so you can not access the disk while the burner is blanking. If > this is the case, put each drive on their own ide channel. > It takes hard drive access to switch window focus? Yes, thats a question. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] 2006-02-10 19:39 ` Gene Heskett @ 2006-02-10 20:12 ` Kyle Moffett 2006-02-10 21:00 ` Gene Heskett 0 siblings, 1 reply; 89+ messages in thread From: Kyle Moffett @ 2006-02-10 20:12 UTC (permalink / raw) To: gene.heskett; +Cc: linux-kernel On Feb 10, 2006, at 14:39, Gene Heskett wrote: > On Friday 10 February 2006 14:19, Phillip Susi wrote: >> Marc Koschewski wrote: >>> I just tried blanking a CD-RW with the latest -git tree. The >>> machine just became unresponsive and then froze. When it became >>> unresponsive the clock in GNOME still displayed the current time >>> but I could not focus any windows anymore. Then I had to hard >>> reboot the machine. The logs say nothing. I repeat: nothing. >>> >>> Does anyone have similar problems? >> >> Instead of rebooting, just wait for the blanking to finish. My >> guess is that your burner and hard drive are both on the same ide >> channel, and so you can not access the disk while the burner is >> blanking. If this is the case, put each drive on their own ide >> channel. > > It takes hard drive access to switch window focus? Yes, thats a > question. Depends on your programs and RAM. If the program you try to switch to (or, say, part of X or your window manage) is swapped out for some reason, then yes, changing focus may cause said program to hang until it can swap the data in. Usually that's a small fraction of a second, but if your IDE bus is waiting for a burn, then it could be the duration of the burn. Cheers, Kyle Moffett -- Premature optimization is the root of all evil in programming -- C.A.R. Hoare ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] 2006-02-10 20:12 ` Kyle Moffett @ 2006-02-10 21:00 ` Gene Heskett 0 siblings, 0 replies; 89+ messages in thread From: Gene Heskett @ 2006-02-10 21:00 UTC (permalink / raw) To: linux-kernel On Friday 10 February 2006 15:12, Kyle Moffett wrote: >On Feb 10, 2006, at 14:39, Gene Heskett wrote: >> On Friday 10 February 2006 14:19, Phillip Susi wrote: >>> Marc Koschewski wrote: >>>> I just tried blanking a CD-RW with the latest -git tree. The >>>> machine just became unresponsive and then froze. When it became >>>> unresponsive the clock in GNOME still displayed the current time >>>> but I could not focus any windows anymore. Then I had to hard >>>> reboot the machine. The logs say nothing. I repeat: nothing. >>>> >>>> Does anyone have similar problems? >>> >>> Instead of rebooting, just wait for the blanking to finish. My >>> guess is that your burner and hard drive are both on the same ide >>> channel, and so you can not access the disk while the burner is >>> blanking. If this is the case, put each drive on their own ide >>> channel. >> >> It takes hard drive access to switch window focus? Yes, thats a >> question. > >Depends on your programs and RAM. If the program you try to switch >to (or, say, part of X or your window manage) is swapped out for some >reason, then yes, changing focus may cause said program to hang until >it can swap the data in. Usually that's a small fraction of a >second, but if your IDE bus is waiting for a burn, then it could be >the duration of the burn. > >Cheers, >Kyle Moffett > Entirely possible I suppose, but I've seen it here quite a few times when there was no swap involved, I've a gig of ram, so I would, just on the evidence, have to assume something went gaga and its time to hit the reset button. cd blanking here is a just a few seconds operation generally as I don't normally do the whole disk, thats a waste of time. I've seen swap used here only one time since I rebuilt with a gig of ram nearly 2 years ago now. Uptime about 2 days, memory according to htop is 384 megs used. >-- >Premature optimization is the root of all evil in programming > -- C.A.R. Hoare -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] 2006-02-10 19:19 ` Phillip Susi 2006-02-10 19:39 ` Gene Heskett @ 2006-02-10 21:00 ` Marc Koschewski 2006-02-10 21:26 ` Phillip Susi ` (2 more replies) 1 sibling, 3 replies; 89+ messages in thread From: Marc Koschewski @ 2006-02-10 21:00 UTC (permalink / raw) To: Phillip Susi; +Cc: Marc Koschewski, linux-kernel * Phillip Susi <psusi@cfl.rr.com> [2006-02-10 14:19:16 -0500]: > Marc Koschewski wrote: > >I just tried blanking a CD-RW with the latest -git tree. The machine just > >became > >unresponsive and then froze. When it became unresponsive the clock in > >GNOME still > >displayed the current time but I could not focus any windows anymore. Then > >I had > >to hard reboot the machine. The logs say nothing. I repeat: nothing. > > > >Does anyone have similar problems? > > Instead of rebooting, just wait for the blanking to finish. My guess is > that your burner and hard drive are both on the same ide channel, and so > you can not access the disk while the burner is blanking. If this is > the case, put each drive on their own ide channel. I've been waiting 30 minutes for the machine to come back but no chance. SSH didn't work either. I thought I could login remote... but uh uh. The problem is, it's a laptop. So there not much chance to move the cdrom device over to another controller or whatever. ;) But let's face it: is it really crappy to render a laptop unusable just because blanking a CD-RW. The circumstances were: run xcdroast via gksu (thus running as root), blank CD-RW. Due to cd-burning being totally unusable as a user (problems here and there if it was just doing anything at all). So I've no other chance than to run this as root. Couldn't cdrecord 'watch' ide load or - even better - forcecast it? It knows blanking leads to inresponsiveness sometimes (even more due to the fact that both devices share the same bus). Why not kind of 'renice' the process that blanks? Marc ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] 2006-02-10 21:00 ` Marc Koschewski @ 2006-02-10 21:26 ` Phillip Susi 2006-02-10 21:35 ` Lennart Sorensen 2006-02-11 15:16 ` CD-blanking leads to machine freeze with current -git Jan Engelhardt 2006-02-10 23:23 ` CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] Alan Cox 2006-02-11 1:03 ` hackmiester (Hunter Fuller) 2 siblings, 2 replies; 89+ messages in thread From: Phillip Susi @ 2006-02-10 21:26 UTC (permalink / raw) To: Marc Koschewski; +Cc: linux-kernel Marc Koschewski wrote: > I've been waiting 30 minutes for the machine to come back but no chance. SSH > didn't work either. I thought I could login remote... but uh uh. > > The problem is, it's a laptop. So there not much chance to move the cdrom device > over to another controller or whatever. ;) > > But let's face it: is it really crappy to render a laptop unusable just because > blanking a CD-RW. The circumstances were: run xcdroast via gksu (thus running as > root), blank CD-RW. Due to cd-burning being totally unusable as a user (problems > here and there if it was just doing anything at all). So I've no other chance > than to run this as root. Couldn't cdrecord 'watch' ide load or - even better - > forcecast it? It knows blanking leads to inresponsiveness sometimes (even more due > to the fact that both devices share the same bus). Why not kind of 'renice' > the process that blanks? > > Marc If that is what is going on, there is nothing linux can do about it; it's a limitation of the hardware. The IDE controller can only accept one command at a time, so if that command takes a while to complete, the other drive on the same channel can not be accessed until the first command completes. If the system doesn't come back though after sufficient time has gone by for the burn to complete, then this is probably not what is happening. I'd suggest using magic-sysreq to force an unmount and reboot, then see if there's anything in the logs. ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] 2006-02-10 21:26 ` Phillip Susi @ 2006-02-10 21:35 ` Lennart Sorensen 2006-02-11 15:16 ` CD-blanking leads to machine freeze with current -git Jan Engelhardt 1 sibling, 0 replies; 89+ messages in thread From: Lennart Sorensen @ 2006-02-10 21:35 UTC (permalink / raw) To: Phillip Susi; +Cc: Marc Koschewski, linux-kernel On Fri, Feb 10, 2006 at 04:26:01PM -0500, Phillip Susi wrote: > If that is what is going on, there is nothing linux can do about it; > it's a limitation of the hardware. The IDE controller can only accept > one command at a time, so if that command takes a while to complete, the > other drive on the same channel can not be accessed until the first > command completes. > > If the system doesn't come back though after sufficient time has gone by > for the burn to complete, then this is probably not what is happening. > I'd suggest using magic-sysreq to force an unmount and reboot, then see > if there's anything in the logs. Perhaps a good test would be to try cdrecord from the command line to blank the cd, to avoid issues to do with X, xcdroast, etc. Just the minimum you can have. Also what command line does xcdroast generate for the blanking? Len Sorensen ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD-blanking leads to machine freeze with current -git 2006-02-10 21:26 ` Phillip Susi 2006-02-10 21:35 ` Lennart Sorensen @ 2006-02-11 15:16 ` Jan Engelhardt 2006-02-11 15:25 ` Marc Koschewski 1 sibling, 1 reply; 89+ messages in thread From: Jan Engelhardt @ 2006-02-11 15:16 UTC (permalink / raw) To: Phillip Susi; +Cc: Marc Koschewski, linux-kernel > > If that is what is going on, there is nothing linux can do about it; it's a > limitation of the hardware. The IDE controller can only accept one command at > a time, so if that command takes a while to complete, the other drive on the > same channel can not be accessed until the first command completes. CD blanking only takes "one" command for the whole operation, as e.g. compared to CD writing where you always have to push out data packets. Why I think it's just one (note the quotes): You can interrupt/kill cdrecord in the midst of blanking a CD, and blanking will continue to the 'end' (either fast blank or full blank, whichever was sent) As mentioned some time earlier, I had similar, but not the same issues. I could continue accessing the harddrive - otherwise mplayer would have stopped immediately, but it played at least until EOF. > If the system doesn't come back though after sufficient time has gone by for > the burn to complete, then this is probably not what is happening. I'd suggest > using magic-sysreq to force an unmount and reboot, then see if there's anything > in the logs. Jan Engelhardt -- ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD-blanking leads to machine freeze with current -git 2006-02-11 15:16 ` CD-blanking leads to machine freeze with current -git Jan Engelhardt @ 2006-02-11 15:25 ` Marc Koschewski 2006-02-11 15:35 ` Doug McNaught 0 siblings, 1 reply; 89+ messages in thread From: Marc Koschewski @ 2006-02-11 15:25 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Phillip Susi, Marc Koschewski, linux-kernel * Jan Engelhardt <jengelh@linux01.gwdg.de> [2006-02-11 16:16:58 +0100]: > > > > If that is what is going on, there is nothing linux can do about it; it's a > > limitation of the hardware. The IDE controller can only accept one command at > > a time, so if that command takes a while to complete, the other drive on the > > same channel can not be accessed until the first command completes. > > CD blanking only takes "one" command for the whole operation, as > e.g. compared to CD writing where you always have to push out data packets. The cdrecord man page says this: Setting the -immed flag will request the command to return immediately while the operation proceeds in background, making the bus usable for the other devices and avoiding the system freeze. This is an experimental feature which may work or not, depending on the model of the CD/DVD writer. A correct solution would be to set up a correct cabling but there seem to be notebooks around that have been set up the wrong way by the manufacturer. As it is impossible to fix this problem in notebooks, the -immed option has been added. It how can the bus run the command sent on the device 'in the background' when it can only process _one_ request at a time? To me it sound like the foreground process (cdrecord) fork()s a process to blank the CD-RW. Clear. But you said the bus is not able to do so... I'm not getting this. > > Why I think it's just one (note the quotes): You can interrupt/kill > cdrecord in the midst of blanking a CD, and blanking will continue to the > 'end' (either fast blank or full blank, whichever was sent) > > As mentioned some time earlier, I had similar, but not the same issues. I > could continue accessing the harddrive - otherwise mplayer would have > stopped immediately, but it played at least until EOF. > > > If the system doesn't come back though after sufficient time has gone by for > > the burn to complete, then this is probably not what is happening. I'd suggest > > using magic-sysreq to force an unmount and reboot, then see if there's anything > > in the logs. > > > Jan Engelhardt > -- > Marc ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD-blanking leads to machine freeze with current -git 2006-02-11 15:25 ` Marc Koschewski @ 2006-02-11 15:35 ` Doug McNaught 2006-02-11 15:44 ` Marc Koschewski 0 siblings, 1 reply; 89+ messages in thread From: Doug McNaught @ 2006-02-11 15:35 UTC (permalink / raw) To: Marc Koschewski; +Cc: Jan Engelhardt, Phillip Susi, linux-kernel Marc Koschewski <marc@osknowledge.org> writes: > The cdrecord man page says this: > > Setting the -immed flag will request the command to return > immediately while the operation proceeds in background, making > the bus usable for the other devices and avoiding the system > freeze. This is an experimental feature which may work or > not, depending on the model of the CD/DVD writer. A correct > solution would be to set up a correct cabling but there seem > to be notebooks around that have been set up the wrong way by > the manufacturer. As it is impossible to fix this problem in > notebooks, the -immed option has been added. > It how can the bus run the command sent on the device 'in the >background' when it can only process _one_ request at a time? > > To me it sound like the foreground process (cdrecord) fork()s a >process to blank the CD-RW. Clear. But you said the bus is not able >to do so... I'm not getting this. Some CD writers are apparently able to release the bus while blanking, allowing use of the bus by other devices. The 'immed' flag tries to use this feature. fork() has nothing to do with it--he's talking about the IDE command, not the cdrecord program. -Doug ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD-blanking leads to machine freeze with current -git 2006-02-11 15:35 ` Doug McNaught @ 2006-02-11 15:44 ` Marc Koschewski 0 siblings, 0 replies; 89+ messages in thread From: Marc Koschewski @ 2006-02-11 15:44 UTC (permalink / raw) To: Doug McNaught; +Cc: Marc Koschewski, Jan Engelhardt, Phillip Susi, linux-kernel * Doug McNaught <doug@mcnaught.org> [2006-02-11 10:35:19 -0500]: > Marc Koschewski <marc@osknowledge.org> writes: > > > The cdrecord man page says this: > > > > Setting the -immed flag will request the command to return > > immediately while the operation proceeds in background, making > > the bus usable for the other devices and avoiding the system > > freeze. This is an experimental feature which may work or > > not, depending on the model of the CD/DVD writer. A correct > > solution would be to set up a correct cabling but there seem > > to be notebooks around that have been set up the wrong way by > > the manufacturer. As it is impossible to fix this problem in > > notebooks, the -immed option has been added. > > > It how can the bus run the command sent on the device 'in the > >background' when it can only process _one_ request at a time? > > > > To me it sound like the foreground process (cdrecord) fork()s a > >process to blank the CD-RW. Clear. But you said the bus is not able > >to do so... I'm not getting this. > > Some CD writers are apparently able to release the bus while > blanking, allowing use of the bus by other devices. The 'immed' flag > tries to use this feature. fork() has nothing to do with it--he's > talking about the IDE command, not the cdrecord program. I just thought about fork() as Alan (surely and others) told the IDE bus cannot run several commands at a time. So fork() was the only left-over I could think of. I didn't know some devices can kinda 'detach' themselves as long as the blank is going on... Things are clear now. OK, more clear. Not clear. ;) Marc ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] 2006-02-10 21:00 ` Marc Koschewski 2006-02-10 21:26 ` Phillip Susi @ 2006-02-10 23:23 ` Alan Cox 2006-02-10 23:41 ` Marc Koschewski 2006-02-11 1:03 ` hackmiester (Hunter Fuller) 2 siblings, 1 reply; 89+ messages in thread From: Alan Cox @ 2006-02-10 23:23 UTC (permalink / raw) To: Marc Koschewski; +Cc: Phillip Susi, linux-kernel On Gwe, 2006-02-10 at 22:00 +0100, Marc Koschewski wrote: > than to run this as root. Couldn't cdrecord 'watch' ide load or - even better - > forcecast it? It knows blanking leads to inresponsiveness sometimes (even more due > to the fact that both devices share the same bus). Why not kind of 'renice' > the process that blanks? It isn't about load. You issue a command to an ATA device and there is no disconnect sequence as SCSI has. That bus is now locked until the command completes. There are mechanisms for certain cases like blanking and fixating that allow you to avoid this. Some cd record apps let you choose them. There isn't anything the kernel can do however. Alan ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] 2006-02-10 23:23 ` CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] Alan Cox @ 2006-02-10 23:41 ` Marc Koschewski 2006-02-10 23:50 ` CD-blanking leads to machine freeze with current -git Doug McNaught 2006-02-10 23:56 ` CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] Alan Cox 0 siblings, 2 replies; 89+ messages in thread From: Marc Koschewski @ 2006-02-10 23:41 UTC (permalink / raw) To: Alan Cox; +Cc: Marc Koschewski, Phillip Susi, linux-kernel * Alan Cox <alan@lxorguk.ukuu.org.uk> [2006-02-10 23:23:54 +0000]: > On Gwe, 2006-02-10 at 22:00 +0100, Marc Koschewski wrote: > > than to run this as root. Couldn't cdrecord 'watch' ide load or - even better - > > forcecast it? It knows blanking leads to inresponsiveness sometimes (even more due > > to the fact that both devices share the same bus). Why not kind of 'renice' > > the process that blanks? > > It isn't about load. You issue a command to an ATA device and there is > no disconnect sequence as SCSI has. That bus is now locked until the > command completes. > > There are mechanisms for certain cases like blanking and fixating that > allow you to avoid this. Some cd record apps let you choose them. There > isn't anything the kernel can do however. > > Alan Alan, I'm curious what caused the machine to freeze now whereas it didn't some kernels ago. I don't know when I blanked a whole CD-RW the last time. But I know it didn't freeze the machine. OK, maybe it's caused by some setting I missed (or enabled) but I use the config now for along time. :/ I'm also curious when DELL will release their first mobile with SCSI onboard instead of IDE. The chips are the same size... Thanks anyone for clarification. There's still sooo much to learn. But the code is here and I'll try to do my very best... ;) Marc ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD-blanking leads to machine freeze with current -git 2006-02-10 23:41 ` Marc Koschewski @ 2006-02-10 23:50 ` Doug McNaught 2006-02-10 23:56 ` CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] Alan Cox 1 sibling, 0 replies; 89+ messages in thread From: Doug McNaught @ 2006-02-10 23:50 UTC (permalink / raw) To: Marc Koschewski; +Cc: Alan Cox, Phillip Susi, linux-kernel Marc Koschewski <marc@osknowledge.org> writes: > I'm also curious when DELL will release their first mobile with SCSI > onboard instead of IDE. The chips are the same size... That's very unlikely to ever happen, but I do hear that laptops are starting to use SATA rather than IDE, at least for the hard disk. That would help with the bus-locking problem... -Doug ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] 2006-02-10 23:41 ` Marc Koschewski 2006-02-10 23:50 ` CD-blanking leads to machine freeze with current -git Doug McNaught @ 2006-02-10 23:56 ` Alan Cox 1 sibling, 0 replies; 89+ messages in thread From: Alan Cox @ 2006-02-10 23:56 UTC (permalink / raw) To: Marc Koschewski; +Cc: Phillip Susi, linux-kernel On Sad, 2006-02-11 at 00:41 +0100, Marc Koschewski wrote: > I'm also curious when DELL will release their first mobile with SCSI onboard > instead of IDE. The chips are the same size... SCSI I think is dead, but SATA is normally one device per bus so the problem goes away > Thanks anyone for clarification. There's still sooo much to learn. But the code > is here and I'll try to do my very best... ;) The magic cdrecord option is "-immed" ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] 2006-02-10 21:00 ` Marc Koschewski 2006-02-10 21:26 ` Phillip Susi 2006-02-10 23:23 ` CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] Alan Cox @ 2006-02-11 1:03 ` hackmiester (Hunter Fuller) 2006-02-11 1:08 ` Marc Koschewski 2 siblings, 1 reply; 89+ messages in thread From: hackmiester (Hunter Fuller) @ 2006-02-11 1:03 UTC (permalink / raw) To: Marc Koschewski, linux-kernel Hrm. ssh into the box and then try to blank the CD on the local machine. Is the ssh session still responsive? I suspect it will be, especially if the GNOME clock's still running. -- --hackmiester Walk a mile in my shoes and you will be a mile away in a new pair of shoes. Marc Koschewski wrote: > * Phillip Susi <psusi@cfl.rr.com> [2006-02-10 14:19:16 -0500]: > > >>Marc Koschewski wrote: >> >>>I just tried blanking a CD-RW with the latest -git tree. The machine just >>>became >>>unresponsive and then froze. When it became unresponsive the clock in >>>GNOME still >>>displayed the current time but I could not focus any windows anymore. Then >>>I had >>>to hard reboot the machine. The logs say nothing. I repeat: nothing. >>> >>>Does anyone have similar problems? >> >>Instead of rebooting, just wait for the blanking to finish. My guess is >>that your burner and hard drive are both on the same ide channel, and so >>you can not access the disk while the burner is blanking. If this is >>the case, put each drive on their own ide channel. > > > I've been waiting 30 minutes for the machine to come back but no chance. SSH > didn't work either. I thought I could login remote... but uh uh. > > The problem is, it's a laptop. So there not much chance to move the cdrom device > over to another controller or whatever. ;) > > But let's face it: is it really crappy to render a laptop unusable just because > blanking a CD-RW. The circumstances were: run xcdroast via gksu (thus running as > root), blank CD-RW. Due to cd-burning being totally unusable as a user (problems > here and there if it was just doing anything at all). So I've no other chance > than to run this as root. Couldn't cdrecord 'watch' ide load or - even better - > forcecast it? It knows blanking leads to inresponsiveness sometimes (even more due > to the fact that both devices share the same bus). Why not kind of 'renice' > the process that blanks? > > Marc > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] 2006-02-11 1:03 ` hackmiester (Hunter Fuller) @ 2006-02-11 1:08 ` Marc Koschewski 0 siblings, 0 replies; 89+ messages in thread From: Marc Koschewski @ 2006-02-11 1:08 UTC (permalink / raw) To: hackmiester (Hunter Fuller); +Cc: Marc Koschewski, linux-kernel * hackmiester (Hunter Fuller) <hackmiester@hackmiester.com> [2006-02-10 19:03:30 -0600]: > Hrm. ssh into the box and then try to blank the CD on the local machine. > Is the ssh session still responsive? I suspect it will be, especially if > the GNOME clock's still running. The clock stopped working after a while. I guess sshd would just 'die away' as any other process did in that case. I'll try with the flag set as Alan suggested. Marc ^ permalink raw reply [flat|nested] 89+ messages in thread
[parent not found: <5zENZ-72l-47@gated-at.bofh.it>]
[parent not found: <5AiBB-5AH-17@gated-at.bofh.it>]
[parent not found: <5AiV2-62l-7@gated-at.bofh.it>]
[parent not found: <5AJ9s-2go-23@gated-at.bofh.it>]
[parent not found: <5AKHI-4IV-5@gated-at.bofh.it>]
[parent not found: <5AKRr-4V5-19@gated-at.bofh.it>]
* Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] [not found] ` <5AKRr-4V5-19@gated-at.bofh.it> @ 2006-01-31 1:01 ` Robert Hancock 0 siblings, 0 replies; 89+ messages in thread From: Robert Hancock @ 2006-01-31 1:01 UTC (permalink / raw) To: linux-kernel Joerg Schilling wrote: > There is no such bug in libscg. > > There is nothing that has been freezed. > > If you have the apropriate privs to send SCSI commands to any SCSI device > on the system, you will not come across your problem. > > Now let us try to talk about real problems or stop this discussion. It appears that you are wanting to blame all of these problems on Linux and refuse to accept the possibility that cdrecord/libscg is doing things incorrectly from a Linux perspective. If you want to "talk about real problems" you must accept this possibility. Why should I have to give privileges to send SCSI commands to any device in the system just to write CDs? The answer, it would appear, is that cdrecord is messing with things (i.e. /dev/sg interface) it has no business messing with in current Linux systems, since that interface should not be necessary for the purpose of cdrecord. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ ^ permalink raw reply [flat|nested] 89+ messages in thread
end of thread, other threads:[~2006-02-11 15:45 UTC | newest] Thread overview: 89+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-01-27 16:37 CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] Bartlomiej Zolnierkiewicz 2006-01-29 11:01 ` Joerg Schilling 2006-01-29 11:15 ` Jan Engelhardt 2006-01-29 11:28 ` Matthias Andree 2006-01-30 15:24 ` Joerg Schilling 2006-02-05 12:03 ` Jan Engelhardt 2006-02-06 16:29 ` Joerg Schilling 2006-02-06 17:17 ` René Rebe 2006-02-06 18:02 ` Matthias Andree 2006-01-29 11:26 ` Matthias Andree 2006-01-29 20:41 ` Jan Engelhardt 2006-01-29 20:50 ` Joerg Schilling 2006-01-29 21:28 ` Albert Cahalan 2006-01-30 16:11 ` Joerg Schilling 2006-01-30 16:31 ` Albert Cahalan 2006-01-30 16:35 ` Joerg Schilling 2006-01-30 17:08 ` Matthias Andree 2006-01-30 17:14 ` Joerg Schilling 2006-01-30 17:30 ` Matthias Andree 2006-01-30 17:37 ` Joerg Schilling 2006-01-30 17:49 ` Matthias Andree 2006-01-30 20:22 ` James Courtier-Dutton 2006-01-31 10:17 ` Andreas Jellinghaus 2006-01-30 20:24 ` Phillip Susi 2006-01-31 10:47 ` Joerg Schilling 2006-01-31 11:22 ` Matthias Andree 2006-02-01 0:15 ` Bill Davidsen 2006-02-01 7:45 ` Tejun Heo 2006-02-01 16:41 ` Joerg Schilling 2006-01-31 23:55 ` Bill Davidsen 2006-02-01 15:06 ` Joerg Schilling 2006-01-30 15:25 ` Joerg Schilling 2006-01-30 17:09 ` Matthias Andree 2006-01-30 17:15 ` Joerg Schilling 2006-01-30 23:26 ` Pavel Machek 2006-02-01 15:51 ` Jan Engelhardt 2006-01-31 1:43 ` Patrick McFarland 2006-01-31 1:47 ` CD writing in future Linux try #2 David S. Miller 2006-01-31 11:13 ` Gerhard Mack 2006-01-31 11:18 ` David S. Miller 2006-02-01 0:28 ` Bill Davidsen 2006-02-01 15:12 ` Joerg Schilling 2006-02-01 15:25 ` Matthias Andree 2006-02-01 16:32 ` Joerg Schilling 2006-02-02 16:24 ` Jan Engelhardt 2006-02-02 16:29 ` Jan Engelhardt 2006-02-02 18:37 ` Bill Davidsen 2006-02-03 12:58 ` Joerg Schilling 2006-02-03 13:15 ` Matthias Andree 2006-02-03 16:43 ` Joerg Schilling 2006-02-03 13:30 ` linux-os (Dick Johnson) 2006-02-03 19:27 ` Bill Davidsen 2006-02-01 4:49 ` Albert Cahalan 2006-02-01 7:56 ` jerome lacoste 2006-02-01 16:42 ` Joerg Schilling 2006-02-02 0:30 ` Kurt Wall 2006-02-01 11:33 ` Rene Herman 2006-02-01 16:21 ` Jon Agirre 2006-02-02 16:35 ` Jan Engelhardt 2006-02-06 23:15 ` Peter Chubb 2006-02-07 5:00 ` Albert Cahalan 2006-02-01 16:36 ` Joerg Schilling 2006-02-01 17:01 ` Matthias Andree 2006-02-02 19:17 ` Bill Davidsen 2006-01-31 16:46 ` Lennart Sorensen 2006-01-31 14:15 ` linux-os (Dick Johnson) [not found] ` <515e525f0601302205h4a845f36u12b946515759239a@mail.gmail.com> 2006-01-31 6:46 ` CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] Kyle Moffett 2006-01-31 8:55 ` Pekka Enberg 2006-02-01 0:25 ` Jesper Juhl 2006-02-02 16:45 ` Jan Engelhardt 2006-02-10 17:58 ` CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] Marc Koschewski 2006-02-10 19:19 ` Phillip Susi 2006-02-10 19:39 ` Gene Heskett 2006-02-10 20:12 ` Kyle Moffett 2006-02-10 21:00 ` Gene Heskett 2006-02-10 21:00 ` Marc Koschewski 2006-02-10 21:26 ` Phillip Susi 2006-02-10 21:35 ` Lennart Sorensen 2006-02-11 15:16 ` CD-blanking leads to machine freeze with current -git Jan Engelhardt 2006-02-11 15:25 ` Marc Koschewski 2006-02-11 15:35 ` Doug McNaught 2006-02-11 15:44 ` Marc Koschewski 2006-02-10 23:23 ` CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] Alan Cox 2006-02-10 23:41 ` Marc Koschewski 2006-02-10 23:50 ` CD-blanking leads to machine freeze with current -git Doug McNaught 2006-02-10 23:56 ` CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] Alan Cox 2006-02-11 1:03 ` hackmiester (Hunter Fuller) 2006-02-11 1:08 ` Marc Koschewski [not found] <5zENZ-72l-47@gated-at.bofh.it> [not found] ` <5AiBB-5AH-17@gated-at.bofh.it> [not found] ` <5AiV2-62l-7@gated-at.bofh.it> [not found] ` <5AJ9s-2go-23@gated-at.bofh.it> [not found] ` <5AKHI-4IV-5@gated-at.bofh.it> [not found] ` <5AKRr-4V5-19@gated-at.bofh.it> 2006-01-31 1:01 ` CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] Robert Hancock
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).