burncd + ioctl

[abc at ai1.anchorage.mtaonline.net]

FBSD 4.10

$ burncd -s4 -f/dev/cdrom erase
erasing CD, please wait..
burncd: ioctl(CDRIOCBLANK): Device busy

everyone seems to have this problem, and i have had it myself
for years.  most times, powering off/on fixes it - but if that
is a satisfactory fix for FBSD - i may as well use MS Windows.

this time, no amount of powering off/on is fixing the problem.

i have tried 10 different blank CD's (the problem seems to occur
with blanks most often - usually occuring after a burncd operation
is aborted).  i have seen the bug reports closed with the advice
of turning off DMA, but after trying every single 'atacontrol'
option, nothing changes.

everything works ok as long as i use CD's that have been written
at one time, but nothing works with 'from the store' blanks now.
yet the same drive and CD's work under MS Windows just fine.

please fix this problem.  it's a real pain.
and it's been going on for years.  problem reports
shouldn't be closed because someone resolved something
by powering off and on.  that's MS technique.

i don't suppose i will hear it is fixed, and
i don't suppose anyone has a sure fire way
to get around it - there are no satisfactory
answers on google or in the maillists or bug reports.

so for whatever it's worth, the problems continue.

--

[as an aside, why isn't it 'atactl', i hate having to type out
the whole word - it feels so 'boneheaded' - and how about some
consistency - sometimes it's 'ctl' then 'cntl' then 'control'
- good grief].

[as another aside - i have been using FBSD since the 1.x days, and
ever since the 3.x series - more so in the 4.x series - i have been
able to easily crash/lock up machines - especially in X - especially
when doing multimedia stuff and then CTRL-ALT-F?-ing to a ttyv? terminal.
i hate having to be careful of how heavily i am stressing my machine.
FBSD didn't used to be like that - it used to stand up to any amount
of abuse - and without all the response latency i experience these days.]