> + res = bq27xxx_battery_voltage(di, &val);
> + if (res)
> + return res;
> +
> + mV = val.intval / 1000;
Reading that code I stumbled over the comment in
bq27xxx_battery_voltage saying that it returns millivolts. The code
here, the code in bq27xxx_battery_voltage and power
> I am tempted to leave the "flags" argument in place though, along
> with the "MEMBARRIER_QUERY" flag. Thoughts ?
http://lwn.net/Articles/585415/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
> *
> ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE**
Is it really that bad to warrant this kind of warning? Not knowing
about the issue at all, I read from the original description that the
wastage is four pages of memory times
> Another option would be to make a configure option to just ignore the
> date. I'm not sure if I would like to use MODSIGN when I have to fear
> that the machine wouldn't start when the RTC fails or got set to a wrong
> date.
Or just ignore the date unconditionally. After all, when a certificate
In article you write:
> Interestingly, of the 26 configs that use EXPERT in the default
> clause, 15 of them are in drivers/hid (see below).
Without looking at the code I assume this is due to copy/paste.
Someone perhaps once wrote
> ./drivers/hid/Kconfig: default !EXPERT
when he really intend
> 200Mb had been filled when it had been umounted from /mnt/bootf8
> repartitioned, mke2fs'd, a journal added and a new label written and then
> mounted to /amandatapes.
>
> Something it seems to me, should have forced the re-init, but didn't. So is
Something I stumbled across just a few days ago
> Unaligned memory accesses occur when you try to read N bytes of data starting
> from an address that is not evenly divisible by N (i.e. addr % N != 0).
Should clarify that you mean "with power-of-two N" - even more
strictly this depends on the processor, but I'm pretty sure there is
none which s
> In current architecture, you have to patch kernel IPv6 and IPv4
> protocols when you add new link layer that they don't recognize.
Which is right, because the IP layer is the place which knows how to
map IP addresses to link layer addresses.
IP must know its link layer. E.g. it needs a way to d
> This is a pity, because it would be so easy to make the both stacks
> totally independent of the actual link layers. It only needs one (or
> two) new function pointer in net_device. This function should do the
> conversion from IPv4/IPv6 address into corresponding hardware
> multicast/broadcast a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> > I've replaced exportfs, mountd and nfsd with a newer version and it
> > works now.
>
> What version were you using? I would really like to know.
The system in question was built on a Knoppix release based on Debian
Potato, with updates from Woody
> Will try your patch tomorrow.
...which does not change anything. (As expected.)
Olaf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> There is a place where a failed kstrdup could lead to this, but that
> is rather unlikely and wouldn't be as reproducible as this seems to
> be.
> If you boot up and then immediately shutdown does this error trigger,
> it does it have to be up for a
This is 100% reproducible. It hangs exportfs on shutdown.
Dec 4 19:50:13 glotze kernel: BUG: unable to handle kernel NULL pointer
dereference at virtual address 0040
Dec 4 19:50:13 glotze kernel: printing eip:
Dec 4 19:50:13 glotze kernel: c017254a
Dec 4 19:50:13 glotze kernel: *pde = 00
In article <[EMAIL PROTECTED]> you write:
> The most recent one was yesterday: I had run lsusb in the morning and had no
> problems, but at the end of the day I ran it again, and after outputting 3
> lines of data, it hung, stuck in D-state. So now I have this:
>
> [/home/user]$ ps aux|grep D
> US
> kernel does know that it has been 'disconnected'. One can even justify the
> inconcsistent behavior -- the write definitely has no place to go (now), but
> the read can't be totally sure that there is no possible way anybody could
> ever find the other end and write to it.
For a socket created
> Well, I understand that ipip_rcv does some work cleaning sk_buff.
> But why after that sk_buff cannot be submitted to ip_rcv, not
> netif_rx?
Oops, now I see that you're talking about ip_rcv, not netif_rx...
I'm doing roughly what you're proposing in CIPE (get IP packet
encapsulated in UDP pac
> Yes, I was wrong. But is it possible in similar situation just call
> ip_rcv for the sk_buff?
What does "just call" mean? The additional setup done by the ipip
receiver is the minimum necessary to get the various parameters in the
sk_buff in a clean state (things like making sure all header poi
> I read net/ipv4/ipip.c. It seems to me that ipip_rcv() function after
> "unwrapping" tunelled IP packet creates "virtual Ethernet header" and submit
Does it? ipip_rcv() does this:
iph = skb->nh.iph;
skb->mac.raw = skb->nh.raw;
i.e. the "MAC header" pointer of the packet is the
> or such. tar/cpio and friends don't deal properly with
> a. holes inside of files.
> b. hardlinks between files.
GNU tar handles both of these. (Not particularly efficiently in the
case of sparse files, but that's a minor issue in this case.) See -S flag.
Perhaps more importantly, for a _robus
> * you've ignored the robustness of design behind the UNIX kernel.
> These beasts keep going without falling apart even after serious injuries.
Do you mean design or operation? In fact UNIX design has a number of
serious errors/problems, we just have gotten accustomed to it so much
that we
> This is guaranteed behaviour of UNIX. You get file handles in order, or
> you don't get them at all.
You get the _next free_ file handle in order. What if your program
assumes they are all contiguous, and it is called by some other
program which forgot about FD_CLOEXEC and has some higher fds s
> Optimization use in select: If all "interesting" file id's are known
> to be below "n", then only the first "n" bits in a FD_ISSET need to
> be examined. As soon as the bits are scattered, it takes MUCH longer
> to check for activity
That's an optimization, not a correctness issue.
> f
> Ehh.. I will bet you $10 USD that if libc allocates the next file
> descriptor on the first "malloc()" in user space (in order to use the
> semaphores for mm protection), programs _will_ break.
Of course, but this is a result from sloppy coding. In general, open()
can just return anything and a
> Still have to test copying from a SCSI disk on the same bus as the
> tape drive.
Done (tar c/tar d), no corruption.
Olaf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majord
> problems: just _how_ high woul dyou move it? Would it potentially disturb
> an application that opens thousands of files, and knows that they get
> consecutive file descriptors? Which is _legal_ and well-defined in UNIX.
Only if you close them before. The process may have been started with
arbi
I tested my systems to try to reproduce the recently reported SCSI
tape corruptions. I did not find any errors, the tape works OK.
Linux version 2.4.3 (olaf@bigred) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #1
Sat Mar 31 11:51:54 CEST 2001
K6-III-400, 96MB
NCR53C815 SCSI controller
HP C15
> Umm, no. Counters can be resetable - you just specify that accounting
> programs should not reset them, ever.
>
> The ability to reset counters is extremely useful if you're a human
> looking at the output of iptables -L -v. (I thus far know of no one
> who can memorise the counter values for
> > telling us the Tk library, which for 8 or 10 years has been pretty much
> > *the* X toolkit/widget set for scripting, does not include an interface
> > to X resources?
Of course it does; in an idiosyncratic way (not directly using X
resources) but it does use the X resource file syntax.
> If
> Similarly, if my InPackets are at 102345 at one read, and 2345 the
> next read, and I know that my counter is 32 bits, then I know i've
> wrapped and can do my own math.
No. When you have resettable counters, you don't know if the counter
has wrapped or been reset. Either you have received 2345
[Warning: historical reference ahead.]
> > I'd appreciate it if some of you with slow machines would try running
> > with fast mode on and seeing if that addresses the sluggishness.
>
> I assume that, eventually there will be no slow mode or fast mode
> distinction... just a single fast mode. Ri
> And the problem is that this hits a fast path in the classical news spool
> layout article create path. The code for this assumes that you have
> articles in the range X to Y, and you just got a new article, so you write
> a file called /var/spool/news/group/name/Y+1. You really do not want to
>
>tar cvf - . | gzip -9 | dd of=/dev/tapes/tape0 bs=32k
I have a tool which compresses individual files in a tar archive
instead of the whole archive[1]. That one tries hard to write only in
standard 10kb blocks to emulate tar's behavior towards the drive.
I'll try in a few days (when I'm back
> It scares me that peoples' messages would be denied based on what
> degree of connection they choose to mail via. I sincerely hope that
> the DUL lists only list netblocks that are actively being used for
> spam. This would be sort of like the Usenet Death Penalty, instating
> bans on providers
> a module for 2.4.3 will work for any 2.4.3 kernel that supports modules
> at all (except for the SMP vs UP issue) so it's not the same thing as
No, no, no. This is absolutely and dangerously wrong.
A module depends on the kernel configuration, because it may access
internal data structures of
> 1) The idea of letting a bug "expire" is a good one. One way to do this
> is to incorporate some form of user-base moderation into the bug
> database. Unlike some of the forum systems, there's no reason why we can't
> have tiers of moderators: "maintainers" are the clearinghouse people for
>
> sock_creat(PF_INET, SOCK_DGRAM, IPPROTO_UDP, &sock);
> sin.sin_family = AF_INET;
> sin.sin_port = htons((unsigned short)serv_port);
> sin.sin_addr.s_addr = htonl(INADDR_ANY); /*i am not sure about this*/
Needs the target IP address here.
> msg.msg_name = &sin;
> msg.msglen = sizeof(struct sock
> Yes, but if SMP for Athlons is not supported, what is the point in
> allowing CONFIG_SMP + CONFIG_MK7 (or CONFIG_SMP + CONFIG_MK6)? Such a
> kernel will not run on *any* SMP system, since AMD kernels do not work
> on Intel. If an AMD user really wants to carry around SMP baggage for
> no reaso
> > I was not suggesting ignoring these. OTOH, there is no reason to treat an
> > RST packet as "go away and never ever send traffic to this host again" -
> > i.e. trying another TCP connection, this time with ECN disabled, would be
> > acceptable.
>
> Using a different source port number, even.
> I also really, really, *REALLY* hate them for killing serial ports. It's
> a Bad Idea[TM].
Why, it opens up the market for serial-ports-on-USB devices. HW
manufactures can make significantly more money on that than on $7.95
ISA multi I/O cards[1] ;-)
Olaf
[1] and I still dislike those, becau
> i.e after the kernel calls ip_route_output() and
> ip_route_output_slow() and fails to find a match, i
> need the kernel to somehow "hook-up" with a
> process/daemon(routing protocol) and access a user
> route cache there.
You may try this: http://sites.inka.de/~bigred/sw/rrouted.txt>
Olaf
-
T
In article <[EMAIL PROTECTED]> you write:
> [J Sloan]
> > The module now compiles and gets installed -
> > Unfortunately, attempting to load it does not go well:
> >
> > kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range
>...
> Those symbols are rather generic and rather important.
> this problem is that it would give any internet hackers the ability to
> discover the network topology (including which servers host NDS master
> and replica databases). Not very secure. The concern for Petr is if in
If knowing the server makes it vulnerable, the server has other
problems sti
> The original exploit had nothing to do with filenames masquerading as
> options, it was: ping6 -I ';chmod o+w .'. Then somebody pointed out
Why is there any reason that a shell should be invoked anywhere in the
request_module->modprobe->insmod chain?
If implemented correctly, this attack shoul
The definition of for_each_task() in is based on
init_task. This symbol is exported in Linux 2.2.15 and 2.4.0-test9,
but with a comment which indicates only a special use; it is not
exported in 2.2.9.
Is there an official opinion about whether for_each_task() is intended
to be usable from a modu
> Well it's safer if you are lazy about prototyping varargs functions.
> But of course by doing that you're treading on thin ice anyway, in
> terms of type promotion and portability. So I guess it's much better
> to say "varargs functions MUST be prototyped" and use the registers.
make -Wmissing
> We figured that since we are in user context (do_ioctl) and use
> spin_lock_bh() to protect us from other concurrent threads, it might
> interfere with rtnl_lock() so we remove our lock just before calling
> register_netdev() and lock again upon return but then the whole process just
> stopped a
> > I suppose. Look at what you just stated! This means that a reported
> > value is now worthless.
>
> Correct. And it was always worthless.
Right. The module "use count" is not a use count, it's a lock count.
E.g. a driver may well increase this counter on open and then again
when in a partic
> "MemTotal: %8lu kB\n"
> to something like
> "%8lu kB\n"
The latter form offers no significant advantage over the former at
all - there is nothing that can be expressed as
value
which can't also be expressed as
name: value
or
name=value
and the latter format is significantly easier to parse.
> See Documentation/SubmittingDrivers in a current kernel. (I've mailed you a
Speaking of that file,
< Portability:Pointers are not always 32bits, people do not all have
< floating point and you shouldn't use inline x86 assembler in
< your driver without caref
> > Still, it would be nice to recover that 4 MB when the system
> > doesn't have any memory left.
> Yup. The X server could give back the memory for some cases like the
> background without too much hackery.
Then Linux only needs to implement SIGDANGER, which has been talked
about for years...
> We really need a collection of include files that only
> define the manifest constants and structures used for
> communication with user space. These can then be used both
> by glibc and by the kernel. This yields includes
> and and the former defines a constant API.
> It ideally never changes
> In any case, this requires use of a hash function (sha1) and a block
> cipher (3des). We were going to do a replacement of /dev/random
I don't think it does _have_ to be 3des, which is approximately the
slowest and most tedious to implement cipher known to the world. ;-)
Blowfish would be nicer
> only a alias for a virtual console, therefore it can send signals. I guess
> the break char is simply not set to ^C. use stty to set break to ^c and then
> save the settings to ioctl.save. This will be restored by init. Or if you
> want to avoid init, set stty by hand.
When I ran into this prob
> contributing member of Linux for quite some time, however, the
> architecture of Linux is unnatural to Novell's and Microsoft's
> technologies and Linux is at present incapable of providing the same
> level of Networking capability available with Windows 2000 or NetWare to
> enterprise customers
54 matches
Mail list logo
