if after the main loop the transfer is already block aligned, we still
have to check whether the last vec is a bounce buffer that is shorter
than a complete block, but exceeds the original end of the request. If
so, we have to cut back to the previous block and add a block-sized
bounce buffer instead. Actually that's almost the same case as when the
transfer length is not yet block aligned, and thus we let the same code
handle it. Fixes bug #2584.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26910 a95241bf-73f2-0310-859d-f6bbb57e9c96
loop.
* This is probably the cause for file corruptions as well as bug #2595; will
have another look tomorrow.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26905 a95241bf-73f2-0310-859d-f6bbb57e9c96
third range, not the first.
* This finally closes#1853 again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26904 a95241bf-73f2-0310-859d-f6bbb57e9c96
interfaces. This fixes bug #2227.
Note that when the SATA interface is in AHCI mode it is still failing
due to what seems to be a device manager problem. I will open a separate
bug for it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26902 a95241bf-73f2-0310-859d-f6bbb57e9c96
- update config.h with one generated with the BONE devkit under Zeta, should be enough.
- fixed config.h so it builds (we do have socklen_t, and stdbool.h)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26897 a95241bf-73f2-0310-859d-f6bbb57e9c96
chipset. This should now finally fix bug #1853.
* Instead of reading values directly from the PCI config space, we now just use
the pci_info structure to retrieve them (interrupt, and base address).
* Renamed alloc_mem() to alloc_contiguous() to make clearer what it does.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26886 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Removing _IMPEXP_KERNEL macro along with the COMPILE_FOR_R5 macro
* Also removing Udf namespace
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26884 a95241bf-73f2-0310-859d-f6bbb57e9c96
* segmentCount was potentially set incorrectly. It could be too big,
since we considered all vecs, not only those remaining.
* The main loop condition was incorrect. This would lead to too few
DMABuffer vecs (or none at all) for any but the first IOOperation of a
request. Should fix#2586.
* Correctly offset by vecIndex in debug output.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26881 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Cleaning up AllocationDescriptorList in order to follow our coding guidelines
- Moving methods implentation outside the class
I've already ported udf but I'm going to commit it one file at the time
so it's easier to review, plus I still have to clean up the code.
Please review.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26880 a95241bf-73f2-0310-859d-f6bbb57e9c96
patch applied, the card didn't work at all anymore.
* Minor 80-column/white space cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26879 a95241bf-73f2-0310-859d-f6bbb57e9c96
to be the habbit now.
* Improve PathHandler::Quit() to delete the object in case the BMessenger was
not valid or failed to send the Quit message. This should handle the corner
case that the PathHandler's looper was already Quit(). There could still be
a race condition, although I don't know if it affects local message targets
in Haiku. I added a TODO note for that, but I believe it can be neglected.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26877 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Tracked down the problem[1] to the wrong offset being read from the pci config.
Now matches Realtek's Linux driver. I couldn't find why it worked before as
the value hasn't changed since the original version added to the repository.
This is only verified with my own 8168 but I found no special logic in other
drivers for 8167 or 8169.
[1] See #1853, "RTL8168 recognized but not working"
I don't have the hardware myself to test.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26873 a95241bf-73f2-0310-859d-f6bbb57e9c96
specifying the protection of each page (4 bits per page).
* Added no-op implementation of posix_madvise().
* Replaced a few "addr_t size" parameters by "size_t size".
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26871 a95241bf-73f2-0310-859d-f6bbb57e9c96
inefficient. And while it did check if the handler was not NULL, it would have
resulted in an endless loop if it was. I think we can safely assume we have no
NULL BHandlers in that list though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26870 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Output something if the node monitor message does not contain the expected
fields (Haiku node monitoring is soo much easier...)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26869 a95241bf-73f2-0310-859d-f6bbb57e9c96
* avoid using read/write and block flags for mapping register memory
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26867 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Cast the slider value to double before dividing by 1000 in order to apply
a smooth speed value. Fixes#1470. Thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26866 a95241bf-73f2-0310-859d-f6bbb57e9c96
with the VMCache lock held, and WriteModified() locks itself.
* Added an assertion that the lock is held when calling that method.
* This fixes a KDL as soon as you would have used O_NOCACHE with a file that
had already some pages read in.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26864 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Added skeleton code for setting device mode.
- Next, figure out which bits to set!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26862 a95241bf-73f2-0310-859d-f6bbb57e9c96
the dirent buffer. This fixes Rene's comment about "ls" entering an endless
loop.
* It also didn't access the buffer passed in correctly if it came from userland.
* It now also fills in as many entries in the buffer as fit.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26861 a95241bf-73f2-0310-859d-f6bbb57e9c96
* dir_read() now takes into account that we may have read more than one dir
entry, and calls fix_dirent() for each of them.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26859 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The use of B_{READ|WRITE}_AREA throughout the drivers is surely alarming.
Defining these flags means that *every user* application can access these
buffers read/write, it becomes visible in userspace like any other memory
(just shared among all apps). I would like to ask each driver maintainer
to see if that is really wished here. If you only need one app to be able
to access it, cloning the area would be more appropriate.
* I came across the use of B_ANY_KERNEL_BLOCK_ADDRESS a number of times. This
is almost completely useless for most usages, as it tries to align the
virtual to a multiple of the size of the area. It just makes the allocation
more likely to fail. Please only use where appropriate, and please review
your code.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26858 a95241bf-73f2-0310-859d-f6bbb57e9c96
