Hopefully I'm not asking a really stupid question here, but...
When setting up a signal handler, using sa_handler, there is a
quasi-documented 2nd parameter of 'struct context ctx' passed to the signal
handler. This seems to work on 2.2.12, 2.2.18, and 2.4.5-ac2. According to
As an end user who uses cheap laptops for firewalls, I'm pretty much
against this. I've got 2.2.18, 2.4.4-ac8, and 2.4.4-ac12 installed as
firewall machines on 486 laptops. Why should we (the collective Linux
world, not me personnally, since I'm not a kernel developer) limit the class
As an end user who uses cheap laptops for firewalls, I'm pretty much
against this. I've got 2.2.18, 2.4.4-ac8, and 2.4.4-ac12 installed as
firewall machines on 486 laptops. Why should we (the collective Linux
world, not me personnally, since I'm not a kernel developer) limit the class
Hopefully I'm not asking a really stupid question here, but...
When setting up a signal handler, using sa_handler, there is a
quasi-documented 2nd parameter of 'struct context ctx' passed to the signal
handler. This seems to work on 2.2.12, 2.2.18, and 2.4.5-ac2. According to
[snip]
>
> I gravely hope that nobody gets the idea to design a PCI card
> for the Z8530 without bus master DMA...
>
[snip]
What someone *really* needs to do is design a Z8530 adapter with a USB
interface. The amateur radio community (well, the 56K'ers, at any rate),
would love such a device.
[snip]
I gravely hope that nobody gets the idea to design a PCI card
for the Z8530 without bus master DMA...
[snip]
What someone *really* needs to do is design a Z8530 adapter with a USB
interface. The amateur radio community (well, the 56K'ers, at any rate),
would love such a device. The
[Snip] (Mike writes a bunch a good stuff)
> Yes, bits are free, sort of... That's why an extra decimal
> place is "ok". Keeping precision within an order of magnitude of
> accuracy is within the realm of reasonable. Running out to two decimal
> places for this particular application is
[Snip] (Mike writes a bunch a good stuff)
Yes, bits are free, sort of... That's why an extra decimal
place is ok. Keeping precision within an order of magnitude of
accuracy is within the realm of reasonable. Running out to two decimal
places for this particular application is just
Sigh. What do half the answers always show up seconds after clicking
'Send'?
I see there is a FILL_URB_INT macro in linux/usb.h, but the only things
using it seem to be drivers (as opposed to usbstress, libusb, etc). The
ioctl call supports USBDEVFS_SUBMITURB, but passing a
I was designing a USB based device and was looking through the 2.4.5 kernel
code, and noticed that while it supports bulk, iso, and control types, there
is no support for interrupt types. A grep through the entire kernel source
code reveals that USBDEVFS_URB_TYPE_INTERRUPT defined in
I was designing a USB based device and was looking through the 2.4.5 kernel
code, and noticed that while it supports bulk, iso, and control types, there
is no support for interrupt types. A grep through the entire kernel source
code reveals that USBDEVFS_URB_TYPE_INTERRUPT defined in
Sigh. What do half the answers always show up seconds after clicking
'Send'?
I see there is a FILL_URB_INT macro in linux/usb.h, but the only things
using it seem to be drivers (as opposed to usbstress, libusb, etc). The
ioctl call supports USBDEVFS_SUBMITURB, but passing a
>
> [EMAIL PROTECTED] wrote:
> > Of course, not looking at the sets upon a zero return is a
> fairly obvious
> > optimization as there is little point in doing so.
>
> No; a fairly obvious optimisation is to avoid calling FD_ZERO if you
> can clear the bits individually when you test them.
>
>
[EMAIL PROTECTED] wrote:
Of course, not looking at the sets upon a zero return is a
fairly obvious
optimization as there is little point in doing so.
No; a fairly obvious optimisation is to avoid calling FD_ZERO if you
can clear the bits individually when you test them.
When you
I hope I'm not rehashing anything discussed before, but I couldn't find any
references to this:
In BSD, select() states that when a time out occurs, the bits passed to
select will not be altered. In Linux, which claims BSD compliancy for this
in the man page (but does not state
I hope I'm not rehashing anything discussed before, but I couldn't find any
references to this:
In BSD, select() states that when a time out occurs, the bits passed to
select will not be altered. In Linux, which claims BSD compliancy for this
in the man page (but does not state
>> I looked at the root_mountflags usage and it looks ok, so I put it in
>> the "figure out later" pile.
>>
>> Haven't yet verified if this 'ac' only problem
>
>Think I have it sussed. Time for -ac2
I took down my Jerry Garcia poster, and put up an Alan Cox poster.
2.4.5-ac2 boots like a
>> http://jcwren.com/linux/ac18.txt - ac18 dmesg dump
>> http://jcwren.com/linux/build.txt - sequence I'm using to build
>>
>> The apparent interleaved garbage closer to the bottom is exactly what
came
>> out on the console. (Is linking to the dumps perferred over including it
in
>> the mail, or
>
>> Checking root filesystem. /dev/hde13 is mounted.
>> Cannot continue, aboorting.
>> *** An error occurred during the file system check.
>> *** Dropping you to a shell; the system will reboot
>> *** when you leave the shell.
>
>That means the file system was mounted read/write at boot time.
I have been running 2.4.4-ac11 for a few weeks, and decided to upgrade to
2.4.4-ac18. I applied the patches, compiled, and installed (all per usual),
and when booting, get a kernel panic at the point VFS is trying to mount the
root file system. I started working backwards to find the last kernel
I have been running 2.4.4-ac11 for a few weeks, and decided to upgrade to
2.4.4-ac18. I applied the patches, compiled, and installed (all per usual),
and when booting, get a kernel panic at the point VFS is trying to mount the
root file system. I started working backwards to find the last kernel
Checking root filesystem. /dev/hde13 is mounted.
Cannot continue, aboorting.
*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
That means the file system was mounted read/write at boot time. That
normally
http://jcwren.com/linux/ac18.txt - ac18 dmesg dump
http://jcwren.com/linux/build.txt - sequence I'm using to build
The apparent interleaved garbage closer to the bottom is exactly what
came
out on the console. (Is linking to the dumps perferred over including it
in
the mail, or would folks
I looked at the root_mountflags usage and it looks ok, so I put it in
the figure out later pile.
Haven't yet verified if this 'ac' only problem
Think I have it sussed. Time for -ac2
I took down my Jerry Garcia poster, and put up an Alan Cox poster.
2.4.5-ac2 boots like a champ.
24 matches
Mail list logo
