Hi,
Tim Woodall wrote:
> https://github.com/torvalds/linux/blob/master/include/uapi/linux/cdrom.h
> [...]
> ==4710== Warning: noted but unhandled ioctl 0x5395 with no size/direction
> hints.
ioctl CDROM_LAST_WRITTEN is something which software would call to
determine the readab
On Tue, 25 Mar 2025, Thomas Schmitt wrote:
Hi,
Tim Woodall wrote:
https://github.com/torvalds/linux/blob/master/include/uapi/linux/cdrom.h
[...]
==4710== Warning: noted but unhandled ioctl 0x5395 with no size/direction
hints.
ioctl CDROM_LAST_WRITTEN is something which software would call
Bit of a wild guess/hope that someone might know what this is. I'm
getting a strange error from valgrind about an ioctl that I'm definitely
not calling directly and I've got no idea why it would be trying to do
anything with a cdrom.
https://github.com/torvalds/linux/blob/mast
Hi,
jeremy bentham wrote:
> eject: unable to eject, last error: Inappropriate ioctl for device
The inappropriate ioctl() does not necessarily have to be the reason
of the failure. man 1 eject indicates that several methods are tried.
> The command sees the drive (it's not the qui
Using the eject command I get the following message:
eject: unable to eject, last error: Inappropriate ioctl for device
This is new: I used the drive to install the OS (jessie? Debian 9, anyway)
and I've actually--not too recently--listened to a CD on it.
Feeding The Duck the message d
The drive also does not respond to the physical control on the
case.
--
Dave Williamsd...@eskimo.com
According to
http://lxr.free-electrons.com/source/include/uapi/linux/i2c-dev.h#L69 the
I2C_RDWR_IOCTL_MAX_MSGS
<http://lxr.free-electrons.com/ident?i=I2C_RDWR_IOCTL_MAX_MSGS> is set to
42 yet calling ioctl with more than 2 messages returns without error, but
only the first 2 messages are pro
I'm a developer so I followed you, though I don't know the best solution to
your situation. However, this really isn't a developer list, so I doubt
you'll get high-quality answers. No, I'm not sure what the best list for
your question might be. Maybe kde-devel?
--
Boyd Stephen Smith Jr.
Do an ioctl to set the ring bit. Before this I could set an abort flag and
end the run at this point?
Note that this program uses two file numbers, one for the read-only xringd
thread and one for any operations that need write access. If there were a way
to turn write access on and off
Simple terminations, i.e. in QThread (QT4 thread class) will not stop it!
How might I kill such a thread?
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
the
>following error.
>
> bootlogd: ioctl (/dev/ttyzf, TIOCCONS): Bad file descriptor
Looks like something is not well with /dev/ttyzf. Is it present?
Are you using 'udev' ?
>I pressume that I need to examine the setup file for bootlogd
bootlogd doesn't have a config
t; Nov 20 05:26:20 zwerg pppoe[26980]: Session terminated -- received
PADT
from peer
> Nov 20 05:26:23 zwerg pppd[26979]: LCP terminated by peer
> Nov 20 05:26:24 zwerg pppd[26979]: ioctl(PPPIOCSASYNCMAP):
Inappropriate ioctl for device(25)
> Nov 20 05:26:24 zwerg pppd[26979]: tcflush faile
eway and
>restart the link manually.
>I tried google, and while I found many questions on the issue, there was
>no solution, nor even an explanation why it fails. The manpages on
>tcflush and ioctl tell me next to nothing. It would make no difference
>to me if they'd be written
into the gateway and
restart the link manually.
I tried google, and while I found many questions on the issue, there was
no solution, nor even an explanation why it fails. The manpages on
tcflush and ioctl tell me next to nothing. It would make no difference
to me if they'd be written in chines
Since I started using the release 2.4.0 kernel I am finding billions of
the above error messages on the console from which X is started and in
the syslog and kern.log. This happens whenever an app, such as Gnome
CD player or Musicmatch Jukebox accesses an audio CD. Everything seems
to work OK, bu
#x27;m looking forward to install Linux on
PPC machines, I'm just wondering whether Debian is installable on 42Ts.
> bootpd. I've never set one of these before. And it is saying:
>
> ioctl SIOCSARP: Invalid argument
>
> Anyone has an Idea of what is happen
I am trying to set up a boot server in order to boot and install
debian-ppc in a 43P I have here, but I am failing miserably to set up
bootpd. I've never set one of these before. And it is saying:
ioctl SIOCSARP: Invalid argument
Anyone has an Idea of what is happ
I get this first line of error message when I use gtcd and both when I try
to run workbone. Gtcd is working but every few seconds report "scanning"
and I think that is when this error message appear on the console:
sr1: CDROM (ioctl) reports ILLEGAL REQUEST.
tocentry read: Ope
ermit i get the error Sorry, can't open connection:
/dev/ttyS3 when trying to set the line on it.
now when booting i see hte messagte 'cannot get serial info: inapropriated
ioctl for device' somewhere near the serial section (i have to read this fast,
since i am for some reason u
Dear Friends:
Any one know where i can find more documentatin about ioctl(...)
I want to do an program for serial communications in Linux.
The man pages has little information.
Thank You !
> I'm in the group dip and all files in /etc/ppp, /etc/ppp.chatscript, pon
> and poff are owned by dip.
A normal Debian installation has no /etc/ppp.chatscript.
/etc/chatscripts and /etc/ppp/ should be owned by root but in the dip
group:
drwx--x--- 2 root dip 1024 Dec 22 17:47 /et
ECT -- got it
Mar 4 19:55:51 Toshiba pppd[336]: Serial connection established.
Mar 4 19:55:52 Toshiba pppd[336]: ioctl(PPPIOCGUNIT): Operation not
permitted
Mar 4 19:55:52 Toshiba pppd[336]: ioctl(PPPIOCGDEBUG): Operation not
permitted
Mar 4 19:55:52 Toshiba pppd[336]: Exit.
I'm in the
> >> May 21 13:15:07 muso pppd[1020]: rcvd [IPCP ConfReq id=0x6 >> 00> ]
> >> May 21 13:15:07 muso pppd[1020]: sent [IPCP ConfRej id=0x6 >> 195.64.64.1>]
> >> May 21 13:15:07 muso pppd[1020]: rcvd [IPCP ConfReq id=0x7 >> 195.64.64.1 195.64.69.173> ]
> >> May 21 13:15:07 muso pppd[1020]: sent [I
e "noipdefault" option
for ppp.
--j
>> May 21 13:15:07 muso pppd[1020]: sent [IPCP ConfAck id=0x8 > 00>]
>> May 21 13:15:07 muso pppd[1020]: ioctl(SIOCADDRT) device route: Network is
>> down(100)
>> May 21 13:15:07 muso pppd[1020]: sent [IPCP
Hello Joost,
You will most likely get more expert advice than I can offer, but this
might help.
muso
The two ends agree that muso is to be 195.64.69.173. The remote wants to
be 195.64.64.1 but muso declines. No IP number is negotiated and the
connection fails.
stelo
negotiates
Mar 19 12:0
pppd[1020]: sent [IPCP ConfRej id=0x7 ]
May 21 13:15:07 muso pppd[1020]: rcvd [IPCP ConfReq id=0x8 ]
May 21 13:15:07 muso pppd[1020]: sent [IPCP ConfAck id=0x8 ]
May 21 13:15:07 muso pppd[1020]: ioctl(SIOCADDRT) device route: Network is
down(100)
May 21 13:15:07 muso pppd[1020]: sent [IPCP TermReq i
Hi,
I am trying to set my system clock, but get the error:
/sbin/clock -u -w
ioctl: Invalid argument
Any ideas about what's wrong?
Thanks.
-
Mark Phillips [EMAIL PROT
Nick Busigin writes:
>
> On 26 Oct 1996, John Henders wrote:
>
> > Maybe Debian should take the bold step of not creating /dev/cua* and
> > making sure all Debian packages work correctly with /dev/ttyS*. This
> > would mean making mgetty the only serial line getty, but much as I used
> > to like
On 26 Oct 1996, John Henders wrote:
> Maybe Debian should take the bold step of not creating /dev/cua* and
> making sure all Debian packages work correctly with /dev/ttyS*. This
> would mean making mgetty the only serial line getty, but much as I used
> to like uugetty, the fact that it has had no
In <[EMAIL PROTECTED]> Rick Macdonald <[EMAIL PROTECTED]> writes:
>Joe Emenaker wrote:
>> Why, after years and years of needing them, are the /dev/cua's suddenly,
>> seemingly, obsolete?
>Rather than just saying RTFM, I've gathered it up for you.
[snip]
Maybe Debian should take the bold step o
On Wed, 23 Oct 1996, Daniel Stringfield wrote:
> > Kermit, Minicom, pppd, any modem software you write, mgetty, etc.,
> > must agree on all of the above, and then it works like a dream.
> >
>
> I use DCON.. its DCON that can't OPEN the port... pppd works fine, and
> mgetty work fine.. but its DCO
Pete Harlan ([EMAIL PROTECTED]) wrote:
: > In my experience, I've had to turn MGETTY OFF when I wanted to make an
: > outbound PPP call. Dunno exactly why. I can dial out when I have MGETTY
: > running, if I dial out with something like Minicom.
:
: This is because they're not putting their lock
Joe Emenaker wrote:
> Why, after years and years of needing them, are the /dev/cua's suddenly,
> seemingly, obsolete?
Rather than just saying RTFM, I've gathered it up for you.
=
This is explained in the mgetty file: /usr/doc/m
On Thu, 24 Oct 1996, Pete Harlan wrote:
> Daniel Stringfield says he's using dcon scripting to connect to his
> isp, and that he's using locking in pppd, and that everyone uses
> ttyS3, and that the locks are in the right place, and...
>
> > Actually, MGETTY isn't the one having the problems, its
On Thu, 24 Oct 1996, Pete Harlan wrote:
> > I use DCON.. its DCON that can't OPEN the port... pppd works fine, and
> > mgetty work fine.. but its DCON that can't share the port...
>
> That would happen if DCON is trying to open, say, /dev/cua0, rather
> than /dev/ttyS0. mgetty will get in the
Daniel Stringfield says he's using dcon scripting to connect to his
isp, and that he's using locking in pppd, and that everyone uses
ttyS3, and that the locks are in the right place, and...
> Actually, MGETTY isn't the one having the problems, its the program I use
> to log into my ISP.
>
> I use
> I use DCON.. its DCON that can't OPEN the port... pppd works fine, and
> mgetty work fine.. but its DCON that can't share the port...
That would happen if DCON is trying to open, say, /dev/cua0, rather
than /dev/ttyS0. mgetty will get in the way of that. The Serial Gods
could tell you a lot
"Joe Emenaker" <[EMAIL PROTECTED]> writes:
> Why, after years and years of needing them, are the /dev/cua's suddenly,
> seemingly, obsolete?
There was a post a long while back where the maintainer of the kernel
serial devices said not to use cua's anymore if you can avoid it. He
seemed to be ind
> From: Pete Harlan <[EMAIL PROTECTED]>
[ snip ]
> Look at the compilation options for both of them and make
> sure that they're each using, e.g., "/var/lock/LCK..ttyS0" for the
> lockfile, and that they write their pid in the file in ASCII format
> (not binary). (This is from the Linux FSSTND.)
On Wed, 23 Oct 1996, Pete Harlan wrote:
> > In my experience, I've had to turn MGETTY OFF when I wanted to make an
> > outbound PPP call. Dunno exactly why. I can dial out when I have MGETTY
> > running, if I dial out with something like Minicom.
>
> This is because they're not putting their lo
On Tue, 22 Oct 1996, Joe Emenaker wrote:
> So, as near as I can tell, the modem was answering the modem on
> its own volition just moments before mgetty sent an "ATA" which, I
> believe, toggles the online state (hangs up if off-hook, picks up if
> on-hook). Hence, the two clicks, I guess. So, pu
On Wed, 23 Oct 1996, Philip Hands wrote:
> > In my experience, I've had to turn MGETTY OFF when I wanted to make an
> > outbound PPP call. Dunno exactly why. I can dial out when I have MGETTY
> > running, if I dial out with something like Minicom.
>
> Sounds like your pppd is not getting its lo
On Wed, 23 Oct 1996, Daniel Stringfield wrote:
> > However, this has *not* fixed the bizzare problem with pppd thinking
> > I don't have PPP support compiled in, even though I do.
>
> In my experience, I've had to turn MGETTY OFF when I wanted to make
> an outbound PPP call. Dunno exactly why. I
> In my experience, I've had to turn MGETTY OFF when I wanted to make an
> outbound PPP call. Dunno exactly why. I can dial out when I have MGETTY
> running, if I dial out with something like Minicom.
This is because they're not putting their lockfiles in the same
directory. Look at the compila
> In my experience, I've had to turn MGETTY OFF when I wanted to make an
> outbound PPP call. Dunno exactly why. I can dial out when I have MGETTY
> running, if I dial out with something like Minicom.
Sounds like your pppd is not getting its locks right. Possible causes:
1) it has not been to
On Tue, 22 Oct 1996, Joe Emenaker wrote:
> However, this has *not* fixed the bizzare problem with pppd thinking I
> don't have PPP support compiled in, even though I do.
In my experience, I've had to turn MGETTY OFF when I wanted to make an
outbound PPP call. Dunno exactly why. I can dial out wh
> Also, the person who suggested that I use mgetty seemed to think I was
> kiiky for wanting to use uugetty. Well, if he's listening, I'd like to add
> that, under mgetty, I *still* can't dial out on the modem that mgetty is
> sitting on. The whole reason I wanted to use uugetty was that it suppose
> ...When I call from a normal phone, I hear a ring, a click,
> another click, and then that's it.
>
> A peek at /var/log/mgetty/mg_ttyS0.log shows:
[snip]
> >10/22 16:42:03 yS0 waiting for ``RING'' ** found **
> >10/22 16:42:03 yS0 cannot set controlli
:41:52 yS0 waiting for ``OK'' ** found **
>10/22 16:41:52 yS0 send: AT[0d]
>10/22 16:41:52 yS0 waiting for ``OK'' ** found **
>10/22 16:41:53 yS0 waiting...
>10/22 16:42:03 yS0 waiting for ``RING'' ** found **
>10/22 16:42:03 yS0 cannot set controlli
49 matches
Mail list logo
