...pointed it to a file called /tmp/xxx with a few lines in it and nothing happens! I tried to echo some additional lines to the file they're not reported either.

For the first part to work, you'd have to specify the tail option, e.g. tail => 10, to read/print out the last 10 lines of the file upon starting the script.

The latter part should've worked, though (if you append to the file while the test script is running — which I suppose you did).   As I can't replicate the problem here, I can only suggest you try strace/truss/tusc to check what's going on (or isn't) underneath.

For comparison, on my (Linux) system, I repeatedly (once a second) get the following block

$ strace ./944682.pl
...
nanosleep({1, 0}, {1, 0})               = 0
nanosleep({0, 0}, NULL)                 = 0
lseek(3, 0, SEEK_END)                   = 32
open("/tmp/xxx", O_RDONLY)              = 4
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff3d7d2c00) = -1 ENOTTY (I
+nappropriate ioctl for device)
lseek(4, 0, SEEK_CUR)                   = 0
fstat(4, {st_mode=S_IFREG|0644, st_size=32, ...}) = 0
fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
fstat(4, {st_mode=S_IFREG|0644, st_size=32, ...}) = 0
close(4)                                = 0
lseek(3, 0, SEEK_END)                   = 32
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
...
[download]

when there's no new lines in /tmp/xxx.  And an additional block

...
lseek(3, 72, SEEK_SET)                  = 72
read(3, "foo\n", 4)                     = 4
lseek(3, 0, SEEK_CUR)                   = 76
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({1, 0}, {1, 0})               = 0
nanosleep({0, 0}, NULL)                 = 0
write(1, "foo\n", 4foo
)                    = 4
...
[download]

when a new line has been appended to the file.

BTW, the "Inappropriate ioctl for device" error is meaningless, i.e. to be expected, here.  This is also what you see in $!, when you check that variable even though the actual system/library call in question hasn't failed.  (In other words, you should only interpret that variable, if Perl actually did indicate a failure.)